Skip to content

Commit e7322e3

Browse files
AndebugulinAndebugulin
committed
journaling: Mon Oct 6 03:28:04 PM EEST 2025
1 parent 62c62dc commit e7322e3

File tree

2 files changed

+240
-0
lines changed

2 files changed

+240
-0
lines changed

‎_posts/en-us/1000-01-01-distill.md‎

Lines changed: 135 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,135 @@
1+
---
2+
layout: post
3+
title: "Learning Journal — 2025-10-6 (y/m/d): WebAssembly History & Concepts"
4+
description: "Notes, reflections, and rough experiments on WebAssembly, asm.js, and related tooling."
5+
tags: [learning, webassembly, webdev, research]
6+
giscus_comments: false
7+
date: 2025-10-05
8+
featured: false
9+
slug: learning-2025-10-05-webassembly
10+
authors:
11+
- name: Andrei Gulin
12+
toc:
13+
- name: Overview
14+
- name: Key Takeaways
15+
- name: Background & References
16+
- name: Relevance & Connections
17+
- name: Confusions & Questions
18+
- name: Action Plan
19+
- name: Reflections
20+
- name: Raw Notes
21+
---
22+
23+
# Learning Journal — 2025-10-05: WebAssembly History & Concepts
24+
25+
---
26+
27+
## Overview
28+
29+
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.
30+
31+
I feel like I spent some time jumping between pages, sometimes losing focus, but overall I got a bit clearer picture.
32+
33+
---
34+
35+
## Key Takeaways
36+
37+
1. **asm.js**
38+
39+
* Basically a subset of JS optimized for performance. Mozilla created it to run compiled C/C++ code on browsers.
40+
* My understanding: it’s like a hacky prototype of what Wasm later became.
41+
* Limitation: still parsed as JS → startup slower, more memory overhead.
42+
43+
2. **Emscripten**
44+
45+
* Compiles C/C++ → asm.js (and now Wasm).
46+
* Initially I thought it was “just a compiler,” but it’s a complete toolchain.
47+
* Fun note: got a bit distracted by the name “Emscripten” (Simpsons joke maybe?)
48+
49+
3. **WebAssembly**
50+
51+
* Binary format, sandboxed, runs in browsers.
52+
* Portable and fast. Can be used with JS via imports/exports.
53+
* I still don’t fully get memory management between Wasm and JS — will test later.
54+
55+
4. **Practical implications**
56+
57+
* Knowing asm.js helps me appreciate Wasm design decisions.
58+
* Can now imagine how Rust or C code might run in the browser.
59+
60+
---
61+
62+
## Background & References
63+
64+
* MDN WebAssembly Docs: [link](https://developer.mozilla.org/en-US/docs/WebAssembly)
65+
* Lin Clark – *A Cartoon Intro to WebAssembly*
66+
* Official W3C Wasm proposal, sections 1–3
67+
* Fireship YouTube video: “How WebAssembly Works” (~10 min)
68+
69+
*(Example image of Wasm stack, just placeholder)*
70+
71+
```html
72+
<div class="row mt-8 justify-content-center">
73+
<div class="col-12 col-md-10 col-lg-8 mt-6 mt-md-6 text-center">
74+
<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">
75+
</div>
76+
</div>
77+
```
78+
79+
---
80+
81+
## Relevance & Connections
82+
83+
* This fits my existing knowledge because I know JS, DOM, and web engines.
84+
* Shows why performance-oriented languages can exist in browsers.
85+
* I don’t see strong parallels with earlier topics yet, but I can imagine future Rust → WebAssembly exercises.
86+
* Might relate to future projects: WASI, server-side Wasm, maybe WebGPU integration.
87+
88+
---
89+
90+
## Confusions & Questions
91+
92+
* How exactly does the browser execute Wasm? Is it JIT or AOT compiled?
93+
* Memory: is it shared with JS or copied?
94+
* Debugging: can I set breakpoints in VS Code? Source maps work reliably?
95+
* Security: is it really sandboxed like JS, or are there loopholes?
96+
97+
---
98+
99+
## Action Plan
100+
101+
1. Try writing a minimal Wasm “Hello World” in Rust or C.
102+
2. Load in browser and log memory buffer via JS.
103+
3. Experiment with memory.grow() and see what happens.
104+
4. Review asm.js examples to understand translation pipeline.
105+
5. Track all questions above and see what resources answer them.
106+
107+
---
108+
109+
## Reflections
110+
111+
* Reading Lin Clark’s cartoons was surprisingly helpful — visuals help a lot.
112+
* My attention drifted after ~45 minutes; I should maybe break into 40-min blocks next time.
113+
* Writing this journal helps me consolidate thoughts.
114+
* Felt a bit chaotic jumping between MDN, YouTube, and blogs — maybe I need a single “primary source” first next time.
115+
116+
---
117+
118+
## Raw Notes
119+
120+
> asm.js = proto-Wasm, demonstrates browser can run typed code
121+
> Emscripten = LLVM backend → compiles C/C++ → Wasm
122+
> WebAssembly = binary, sandboxed, runs near-native speed
123+
> Can inspect Wasm memory via `new Uint8Array(memory.buffer)`
124+
> Still confused about memory growth, debug tools, performance differences
125+
126+
> Notes are messy but that’s ok — reflects my thought process
127+
128+
---
129+
130+
## Summary
131+
132+
* **Main insight:** Wasm exists because web needed portable, fast, safe execution for non-JS code.
133+
* **Next steps:** small Rust or C module → compile → run in browser → inspect memory.
134+
135+
---

‎_posts/en-us/2025-10-06-distill.md‎

Lines changed: 105 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,105 @@
1+
---
2+
layout: post
3+
title: "Learning Journal — 2025-10-06 (y/m/d): WebAssembly History & Concepts"
4+
description: "Notes, reflections, and rough experiments on WebAssembly, asm.js, and related tooling."
5+
tags: [learning, webassembly, webdev, research, thesis]
6+
giscus_comments: false
7+
date: 2025-10-06
8+
featured: false
9+
slug: learning-2025-10-05-webassembly
10+
authors:
11+
- name: Andrei Gulin
12+
toc:
13+
- name: Overview
14+
- name: Key Takeaways
15+
- name: Background & References
16+
- name: Relevance & Connections
17+
- name: Confusions & Questions
18+
- name: Action Plan
19+
- name: Reflections
20+
- name: Raw Notes
21+
---
22+
23+
# Learning Journal — 2025-10-06: WebAssembly History & Concepts
24+
25+
---
26+
27+
## Overview
28+
29+
I spent roughly 2 hours understanding how webassembly appeared. Descovered `emscripten` and `asm.js`. Interesting stuff. Helped me understand why webassembly is the way it is.
30+
I feel like I spent some time jumping between pages, sometimes losing focus, but overall I got a bit clearer picture.
31+
32+
---
33+
34+
## Key Takeaways
35+
36+
1. **Emscripten**
37+
38+
* At first compiles `C/C++` to `JS` was original idea
39+
* Dude that worked in `Mozilla` understood that `this compilation` produced some parts that were identical to after parsing `JS` code
40+
it was `C/C++` to `JS`, after that he asked to make `C/C++` to `asm.js` which is a subset of `JS` that is easier to optimize
41+
* When they got approval to make their `asm.js` on all browsers, they decided to really optimize it and make it a `binary format` which is `WebAssembly`
42+
43+
* Funny note: Emscripten name is a reference to Simpsons episode, where they used `embiggen` word which is a made up word
44+
45+
2. **asm.js**
46+
47+
* Basically a subset of `JS` optimized for performance. Mozilla created it to run compiled C/C++ code on browsers.
48+
* Limitation: still parsed as `JS` → startup slower, more memory overhead.
49+
50+
3. **WebAssembly**
51+
52+
* Binary format, sandboxed, runs in browsers.
53+
* I still don’t fully get memory management between Wasm and JS — will test later.
54+
* Its interesting to me that maybe its easier to debug asm.js than webassembly, because its still `JS` after all, and then just recompile to `Wasm` and run it
55+
56+
---
57+
58+
## Background & References
59+
60+
* [why web assembly is fast](https://hacks.mozilla.org/2017/02/what-makes-webassembly-fast/)
61+
* [nice blog, BUT its old and it feels like that people who wrote it didn't know much about asm.js or emscripten](https://www.nutrient.io/blog/webassembly-a-new-hope/)
62+
* [REALLY FUCKING NICE ARTICLE](https://spectrum.ieee.org/webassembly-will-finally-let-you-run-highperformance-applications-in-your-browser)
63+
64+
---
65+
66+
## Relevance & Connections
67+
68+
* Shows why performance-oriented languages can exist in browsers.
69+
* I don’t see strong parallels with earlier topics yet, but I can imagine future Rust → WebAssembly exercises.
70+
* Might relate to future projects: WASI, server-side Wasm, maybe WebGPU integration.
71+
72+
---
73+
74+
## Confusions & Questions
75+
76+
* How exactly does the browser execute Wasm? Is it JIT or AOT compiled?
77+
* How even browser execute JS?
78+
* Memory: is it shared with JS or copied?
79+
* Debugging: can i debug wasm through debugging it in asm.js and then recompiling to wasm?
80+
* Security: no fucking clue yet.
81+
82+
---
83+
84+
## Action Plan
85+
86+
1. Review asm.js examples to understand translation pipeline.
87+
2. Track all questions above and see what resources answer them.
88+
89+
---
90+
91+
## Reflections
92+
93+
* Writing this journal helps me consolidate thoughts and actually think after I learnt something.
94+
95+
---
96+
97+
## Raw Notes
98+
99+
> didn't do this time, need to do next time
100+
101+
---
102+
103+
## Summary
104+
105+
No summary

0 commit comments

Comments
 (0)