WebAssembly from Scratch: From FizzBuzz to DooM (github.com)

Article summary

The article explores WebAssembly from scratch, starting with a simple FizzBuzz implementation and progressing to porting the 1997 game DooM to WebAssembly. The author's goal is to understand WebAssembly without relying on magic tooling or frameworks. The article discusses the challenges of working with WebAssembly, including the lack of strings and DOM API interop. The author demonstrates the potential of WebAssembly by deploying a Rust-compiled FizzBuzz and a port of DooM to GitHub Pages.

Main themes

• WebAssembly limitations
• Language interoperability
• Garbage collection
• Security concerns
• DOM API interop
• WebAssembly use cases

What commenters say

• WebAssembly's lack of strings and DOM API interop is a significant limitation that makes it difficult to work with.
• The design of WebAssembly is intended to provide a simple and efficient compile target, with features like interface types being added to improve its usefulness.
• Some commenters argue that WebAssembly's purpose is not to replace JavaScript, but rather to speed up certain parts of a website or app.
• Others believe that WebAssembly's limitations, such as the lack of garbage collection, make it less useful for certain use cases, such as compiling languages like C# to WebAssembly.
• There is disagreement about whether WebAssembly should have a built-in garbage collector, with some arguing that it would be useful and others believing it is out of scope for the technology.
• The need for bridging code to interact with JavaScript objects is seen as a tedious but necessary task by some, while others believe that libraries and frameworks can alleviate this burden.
• Some commenters are concerned about the security implications of WebAssembly's design, particularly with regards to memory corruption and sandboxing.