Learning Journal — 2025-10-05: WebAssembly History & Concepts

Overview

Today I spent roughly 2 hours trying to understand the origins of WebAssembly. Honestly, I started reading some MDN docs and Lin Clark’s cartoons and got a bit lost at first. I’m still trying to build a mental model of why asm.js existed and how it led to Wasm. I also looked at a few videos and scattered blogs. My goal was not just to know “what” but to see why it matters for web development in general.

I feel like I spent some time jumping between pages, sometimes losing focus, but overall I got a bit clearer picture.

Key Takeaways

1. asm.js

   • Basically a subset of JS optimized for performance. Mozilla created it to run compiled C/C++ code on browsers.
   • My understanding: it’s like a hacky prototype of what Wasm later became.
   • Limitation: still parsed as JS → startup slower, more memory overhead.

2. Emscripten

   • Compiles C/C++ → asm.js (and now Wasm).
   • Initially I thought it was “just a compiler,” but it’s a complete toolchain.
   • Fun note: got a bit distracted by the name “Emscripten” (Simpsons joke maybe?)

3. WebAssembly

   • Binary format, sandboxed, runs in browsers.
   • Portable and fast. Can be used with JS via imports/exports.
   • I still don’t fully get memory management between Wasm and JS — will test later.

4. Practical implications

   • Knowing asm.js helps me appreciate Wasm design decisions.
   • Can now imagine how Rust or C code might run in the browser.

Background & References

• MDN WebAssembly Docs: link
• Lin Clark – A Cartoon Intro to WebAssembly
• Official W3C Wasm proposal, sections 1–3
• Fireship YouTube video: “How WebAssembly Works” (~10 min)

(Example image of Wasm stack, just placeholder)

<div class="row mt-8 justify-content-center">
  <div class="col-12 col-md-10 col-lg-8 mt-6 mt-md-6 text-center">
    <img src="https://developer.mozilla.org/en-US/docs/WebAssembly/wasm-diagram.png" class="img-fluid rounded z-depth-1" alt="WebAssembly in browser stack">
  </div>
</div>

Relevance & Connections

• This fits my existing knowledge because I know JS, DOM, and web engines.
• Shows why performance-oriented languages can exist in browsers.
• I don’t see strong parallels with earlier topics yet, but I can imagine future Rust → WebAssembly exercises.
• Might relate to future projects: WASI, server-side Wasm, maybe WebGPU integration.

Confusions & Questions

• How exactly does the browser execute Wasm? Is it JIT or AOT compiled?
• Memory: is it shared with JS or copied?
• Debugging: can I set breakpoints in VS Code? Source maps work reliably?
• Security: is it really sandboxed like JS, or are there loopholes?

Action Plan

1. Try writing a minimal Wasm “Hello World” in Rust or C.
2. Load in browser and log memory buffer via JS.
3. Experiment with memory.grow() and see what happens.
4. Review asm.js examples to understand translation pipeline.
5. Track all questions above and see what resources answer them.

Reflections

• Reading Lin Clark’s cartoons was surprisingly helpful — visuals help a lot.
• My attention drifted after ~45 minutes; I should maybe break into 40-min blocks next time.
• Writing this journal helps me consolidate thoughts.
• Felt a bit chaotic jumping between MDN, YouTube, and blogs — maybe I need a single “primary source” first next time.

Raw Notes

asm.js = proto-Wasm, demonstrates browser can run typed code Emscripten = LLVM backend → compiles C/C++ → Wasm WebAssembly = binary, sandboxed, runs near-native speed Can inspect Wasm memory via new Uint8Array(memory.buffer) Still confused about memory growth, debug tools, performance differences

Notes are messy but that’s ok — reflects my thought process

Summary

• Main insight: Wasm exists because web needed portable, fast, safe execution for non-JS code.
• Next steps: small Rust or C module → compile → run in browser → inspect memory.