aksaN000 · learning in public

Root to End of Random Technical Concepts

Interactive simulations I build while learning computer science. Each one starts at the lowest layer that matters and traces upward to the code I actually write, using the real source of the systems involved.

In what order does this print?

a 30-second puzzle
log("A");
setTimeout(() => log("B"), 0);
Promise.resolve().then(() => log("C"));
log("D");
Our guess
Pick next

Where to start

Every page has the same shape

  1. 60-second versionThe core rule and one diagram, for the night before the exam.
  2. Frames from the rootReal source, kernel or engine first, our code last.
  3. A labStep it, type into it, and check it against the real system.
  4. Real outputBytes, traces and logs captured from the real tool.
  5. PracticePredict-first quizzes, exam questions and a reading list.

Simulations

Every simulator is our own model, labelled as such on its page and checked against the real system: V8, GNU Bison, Node, scapy, Chromium, PyTorch, npm and Tailwind CSS. What was checked, how, and what is not covered. Reading times count the prose only; the labs take as long as we like.

From the power button to .then()

How one fetch().then() in a React app actually runs in Chrome: the renderer process and its threads, the line that starts the event loop, the kernel wait, and V8's microtask queue.

kernel→RendererMain→run_loop.Run()→MessagePumpDefault→V8→our callback
JavaScriptChromiumV8event loopAbout 25 min

Needs: basic JavaScript and promises.

Open →

One core, two ways to wait

Multi-threading versus event-driven concurrency, from the kernel's schedule() through glibc's clone flags, context_switch, futex mutexes and epoll, with a race-condition stepper and a one-core timeline simulator. Companion to my CSE321 theory assignment.

schedule()→clone / epoll_wait→context_switch→futex→our server
Operating systemsLinuxglibcconcurrencyAbout 20 min

Needs: some C. Pairs well with the event-loop page.

Open →

How V8 turns a + b into machine code

One expression through V8's scanner, precedence-climbing parser, bytecode generator and the Ignition interpreter, then hidden classes, inline caches, tier-up to Maglev and TurboFan, and a real deoptimization. The bytecode model matches Node's V8 output exactly.

scanner→parser→Ignition bytecode→feedback→TurboFan→our function
CompilersV8JITinterpretersAbout 15 min

Needs: basic JavaScript. The LR page helps with the parser part.

Open →

Shift, reduce, accept

Type any grammar and watch an SLR parser get built: FIRST and FOLLOW, LR(0) item sets, the ACTION and GOTO table, then a step-by-step parse that grows its tree. Checked against the Dragon Book and real GNU Bison output, including conflicts.

grammar→items→SLR table→yyparse()→our parse tree
CompilersparsingBisonCSE420About 15 min

Needs: context-free grammars (what a production is).

Open →

What fetch() really sends

One fetch('/api/users') traced through real Chromium: Blink, the network service, DNS, TCP, a post-quantum TLS 1.3 handshake, HTTP/1.1 and CORS. Real captured bytes, a replay of Chrome's own NetLog, and a CORS lab that matches Chrome on 2,880 cases.

fetch()→network service→DNS · TCP · TLS→HTTP→CORS→our promise
Browser track 1/3networkingweb APIsChromiumAbout 25 min

Needs: the event-loop page; TCP/IP basics help.

Open →

From HTML bytes to pixels

Blink's HTML tokenizer and tree builder, stepped token by token on any HTML we type, with a model that builds the same tree as Chrome on 8,929 distinct inputs. Then the rendering lifecycle: real traces showing which stages a color, width or transform change runs, and why a read-after-write loop forced 20 layouts.

bytes→tokens→DOM→style · layout→paint · composite→pixels
Browser track 2/3DOMrenderingBlinkAbout 15 min

Needs: basic HTML and CSS. Browser track page 1 comes first.

Open →

From a click to our listener

One mouse press from the USB report and the Linux kernel through Chrome's browser process, compositor and main thread, the hit test that picks the element, and capture-target-bubble dispatch into our listener. Click a stage of boxes and a set of listeners for real: the hit-test model matches Chrome at 40,320 points and the dispatch model on 1,609 programs, including where the microtasks run.

input_event→browser process→compositor→hit test→dispatch→our listener
Browser track 3/3DOM eventsinputChromiumAbout 20 min

Needs: basic DOM events. The event-loop page explains the microtask part.

Open →

From the chain rule to loss.backward()

How PyTorch computes every gradient: the graph of backward Nodes recorded during the forward pass, the engine's dependency counts and ready queue, and the AccumulateGrad node that writes .grad. Step through any small program; the engine matches real PyTorch on 2,001 programs, node for node and in the same order.

chain rule→grad_fn graph→Engine::execute→AccumulateGrad→loss.backward()
ML track 1/2PyTorchautogradbackpropagationAbout 15 min

Needs: derivatives and the chain rule; a little Python.

Open →

From the engine to the plugin

The words a React project throws at us at once, put where they live: the node binary, runtimes, packages, the registry and scopes, how npm and npx read a command line, Vite's transform hook and its plugins, and the CSS behind a Tailwind class. A command lab matches npm 10 on 4,793 cases and a class lab matches Tailwind CSS 4 on 2,183 classes. It ends with what memory research says about keeping all of it, and a spaced recall trainer.

main()→Node · browser→npm · npx→Vite plugins→Tailwind→our components
Web dev track 1/5npmViteTailwind CSSlearningAbout 25 min

Needs: nothing beyond basic JavaScript. Opens the Web dev track; a good first page before the event-loop page and the Browser track.

Open →

From a JSON file to the screen

Loading data into a React component three ways: plain JavaScript, useEffect with useState, and use(promise) with <Suspense>. We follow each into React 19's source (the hook slots, the effect list, Object.is on the dependency array, the throw that Suspense catches) and step through our own code line by line. A dependency-array lab matches real React 19.2.8 on 720 click programs and can re-run any sequence on real React in the browser.

the DOM→useState→useEffect→use + Suspense→our component
Web dev track 2/5React 19useEffectSuspenseAbout 20 min

Needs: basic JavaScript and promises (fetch, async/await), and a first React component. Follows page 1 of the Web dev track.

Open →

Web dev track

From the tools on our machine to a running React and Next.js app: what npm, Vite and Tailwind do before the browser sees our code, then how a component loads its data, how React turns components into DOM and keeps it up to date, then how Next.js serves a page. It is the path of a first React project, and it hands over to the Browser track for what the browser does next.

Browser track

Three pages that follow one page through the browser, each picking up where the last one stops: the request goes out, the response becomes pixels, and a click on those pixels comes back to our code. They connect to the event-loop page, which shows when each piece of our JavaScript gets to run.

ML track

From a single number to a sentence: how a model learns, then how it produces text. It starts from the chain rule and ends inside a transformer.

How the pages connect

Read left to right to follow source code down to the CPU: a grammar becomes a parser, V8's parser and interpreter run our JavaScript, the event loop decides when, and the kernel decides which thread gets the core.

And sideways, out of the machine: fetch-to-the-wire follows the network request that the event-loop page's wake chain starts from.

And one step before all of it: the Web dev track starts with the tools on our own machine (Node, npm, Vite and its plugins) that prepare the code these pages follow.