# From CPU to the Browser: a curriculum for building a React stack from scratch

> raw-bits-to-react is a twelve week course plan that has a developer build a CPU simulator, a networking layer, a browser rendering engine, a JavaScript engine, a Fiber style reconciler and a React clone in order, so that performance arguments stop being tribal. It suits a senior engineer who wants the mechanisms behind a slow frame, and it is a plan rather than a codebase.

**renderffx/raw-bits-to-react** — CPU → cache → TCP → browser engine → JS VM → Fiber React → 60 fps / learn react like god !

- Repository: https://github.com/renderffx/raw-bits-to-react
- Stars: 1,196 · Forks: 57
- Language: Unknown
- License: not declared
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/renderffx-raw-bits-to-react

## The pipeline diagram is the syllabus

The course is described by a single chain, and it is worth reading slowly because every arrow is a place where a frame budget is spent:

CPU instruction fetch, cache misses, virtual memory page faults, TCP packets, HTTP parsing, HTML and CSS tokenization, layout thrashing, JS bytecode execution, GC pauses, Fiber reconciliation, paint chunks, GPU compositing.

That ordering is the argument of the whole project. A React application that stutters is not a React problem, it is a problem somewhere in that chain, and the claim is that you cannot reason about which stage is responsible unless you know what each stage is.

The stated motivation is blunt about the current state of the ecosystem. Tools like Claude, Cursor and friends generate React components faster than you can read them, but 90% of it is bloated, unoptimized garbage full of unnecessary useEffect chains that turn smooth UIs into slideshows, and many websites today will not run at 60 fps.

The course argues that most of the frustration and complaints around React come from misunderstanding what React was designed to be, and that the complaint that React is slow is usually a symptom of a re-render storm or a state thrashing problem in the application rather than a property of the framework.

And the conclusion drawn is a deliberate one. The only real moat left is craft, with a quotation attributed to Benji Taylor saying that in the age of slop, craft is the differentiator.

The promised outcome is diagnostic rather than theoretical. You will know precisely why your LCP is 4 seconds, which inline cache is polymorphic and exploding, why your 10k-item list janks on scroll, and how a single compositor layer promotion saves 15 ms per frame.

## Twelve weeks, in dependency order

The plan is laid out week by week, and the order is not arbitrary. Nothing later depends on a layer that has not been built.

Week 0.5 is Hardware and Memory Reality, covering the CPU pipeline from fetch through decode, execute and writeback, registers, instruction level parallelism and instruction scheduling, branch prediction with static and dynamic prediction and mispredict penalties, the cache hierarchy with L1 instruction and data, L2 and L3, cache lines, associativity and write policies, virtual memory with paging, the TLB, page faults and huge pages, the process memory layout of text, rodata, data, bss, stack and heap, and pointers with alignment, padding, strict aliasing and the cost of unaligned access. The project is an RV32I CPU simulator with a two level cache, in Rust or C++, measuring branch against cache miss penalties on small loops.

Week 1 is Networking From First Principles, with TCP and UDP sockets, the three way handshake, sequence numbers and acknowledgement, the sliding window, flow and congestion basics, HTTP/1.1 with headers, chunked encoding, keep alive and pipelining, an HTTP/2 introduction covering multiplexing and HPACK, a TLS 1.3 handshake overview with no crypto deep dive, WebSocket with upgrade, framing, masking and ping and pong, and debugging with Wireshark filters, tcpdump and tc and netem latency and loss simulation. The project is a persistent HTTP/1.1 client and server with chunked support, tested under high latency and packet loss.

Weeks 2 and 3 are the browser rendering engine, split into four sub-areas. HTML parsing covers the WHATWG tokenizer with 13 states and 67 transitions, tree construction with error recovery and quirks mode, and script execution timing for blocking, async and defer. The CSS engine covers the tokenizer and parser for selectors, properties and at-rules, specificity and cascade including layers, and computed styles, inheritance and media queries. The layout engine covers the box model, margin collapse and formatting contexts, floats, positioning, the full Flexbox algorithm, the full Grid algorithm, and inline layout, line breaking and text shaping. Paint and composite covers stacking contexts, layer promotion and paint order, display lists and paint chunks, and a basic scanline rasterizer with GPU texture and compositing hints. The project is a browser that renders real Wikipedia pages, logging timings for parse, style, layout, paint and composite.

Weeks 4 and 5 are the JavaScript engine, and the visible part of the plan covers parsing and AST with a lexer, a recursive descent parser, AST construction, scope analysis and hoisting.

## The React clone is the last step, not the first

The point of the ordering is that the React work comes last, and by then the machinery underneath has already been built.

The JavaScript engine stage covers the lexer and recursive descent parser, AST construction, scope analysis and hoisting, then a stack based virtual machine, closures, prototypes and inline caches, a generational garbage collector, and a complete event loop with microtasks, macrotasks, requestAnimationFrame and requestIdleCallback.

The virtual DOM stage is explicitly a progression through three levels. First a naive diff, then keyed O(n) heuristics, and then Fiber style architecture with units of work, yielding and time slicing.

Then the React clone itself, which is listed as a Fiber reconciler, a full hooks system, concurrent features including Suspense, transitions and deferred values, streaming server side rendering, and selective or progressive hydration.

And then a production application layer that is described as Next.js-inspired: file based routing, static site generation and incremental static regeneration, API routes and code splitting, all running on your own stack rather than on the real Next.js.

The final deliverable is an end to end optimized application with sub-second loads, stable 60 fps, graceful handling of 10,000 or more DOM mutations, and survival of extreme hardware and network constraints.

That last line is the honest test of the whole plan. A reconciler you wrote yourself, on a VM you wrote yourself, serving a bundler you wrote yourself, is only worth anything if the result holds up in the browser, and that is why the browser engine and the event loop come before the React work rather than after it.

## The prerequisites are the filter

The course is unusually blunt about who it is for, and the who this is really for section is where the real expectations are set.

You, if you are a senior frontend engineer tired of surface level perf tips and ready to go god-tier, or a backend and systems developer who wants to master high performance user interfaces from first principles, or you are done blaming React and want to understand the real reasons, which it names as caches, garbage collection, layout, compositing and the event loop, or you crave hard, proud-of-it-forever projects.

Not for you, if you want fast dopamine hits or copy-paste code, if low-level words like mark-compact, TLB miss, bailout and paint chunk scare you, or you are not ready to wrestle C++ or Rust for months.

The prerequisites section is the harder filter. You need to write fluent C++ or Rust, with templates, lifetimes and unsafe blocks, and most heavy lifting is here. You need to understand CPU pipelines, branch prediction, cache associativity, virtual memory and the TLB. You need OS basics with processes, syscalls, memory layout and scheduling. You need deep data structures and algorithms comfort. And you need real experience with GDB or LLDB, Valgrind, perf and strace.

That last requirement is the one that decides whether the project is worth attempting. The tooling named is the tooling you need to find out why a thing is slow, and the course's premise is that you will spend twelve weeks building things in order to understand them, which is a different activity from learning to use them well.

The realistic commitment note is the part to read before enrolling. It says 12 core weeks of deep focus, which usually stretches to 4 to 6 months part time.

The type of person the course is aimed at is someone tired of framework arguments. The stated outcome is that when you finish, you will not whine about frameworks and not participate in framework wars.

## What this repository actually is

It is worth being clear about the shape of the artefact, because the name suggests a codebase and there is not one.

The repository contains exactly one file at the top level, `readme.md`. There is no source, no build, no test suite, no licence file and no package manifest. The primary language is recorded as unknown, and the only topic tag is `react`.

So this is a syllabus. Everything described in the plan, from the RV32I simulator to the browser to the JavaScript engine to the reconciler, is something the reader would build. The projects are specified, the week boundaries are given, and the prerequisites are stated, but none of it exists as code yet.

That has consequences for how you should read it. You cannot run it, and you cannot check the claims by reading an implementation. What you can do is use it as a syllabus and as a statement of what a person believes a complete frontend education should contain, and that is a defensible artefact on its own. The progression from hardware to rendering to JavaScript to reconciliation is the argument that you cannot optimise the last layer until you understand the first ones, and a plan that makes that argument explicitly is more useful than most conference talks on the same subject.

The reference material is social rather than technical. The plan points to a thread about how modern React engineers should engineer React applications, with an example tweet and a second thread on the take, and it quotes Benji Taylor on craft. So the ideas are anchored in public arguments rather than in a paper, which is both a strength, since the arguments are live and you can read them, and a weakness, since there is nothing to check the reasoning against.

The licence field is empty, and the last push was on 2026-09-04, so the plan is not being actively revised, and the repository is not archived. For a document like this, that is a reasonable state, but it does mean the week 0.5 through week 12 outline may not reflect the latest thinking of whoever wrote it.

## Conclusion

From CPU to the Browser fits a senior frontend or systems engineer who can already write fluent C++ or Rust and wants the performance vocabulary to be real rather than borrowed, because the course builds each layer of the stack in the order the browser actually uses it. Skip it if you want a framework to adopt rather than mechanisms to learn, and skip it if you do not have the systems background, since the first week assumes you already understand paging, branch prediction and cache associativity. Before you commit, read the realistic commitment note, which says 12 core weeks of deep focus usually stretches to 4 to 6 months part time, and note that the repository contains only a readme, so this is a syllabus you would implement yourself rather than code you would install.

## FAQ

### What is the From CPU to the Browser course?

It is a twelve week plan to build a CPU simulator, a networking layer, a browser rendering engine, a JavaScript engine, a Fiber style reconciler and a React clone in order, so that performance reasoning in a React application is grounded in how the stack actually works.

### How long does the course realistically take?

The realistic commitment is stated as 12 core weeks of deep focus, which usually stretches to 4 to 6 months part time.

### What do I need to know before starting?

Fluent C++ or Rust including templates, lifetimes and unsafe blocks, an understanding of CPU pipelines, branch prediction, cache associativity, virtual memory and the TLB, OS basics, deep data structures and algorithms comfort, and real experience with GDB or LLDB, Valgrind, perf and strace.

### What is in the browser rendering engine part of the plan?

HTML parsing with the WHATWG tokenizer, tree construction, error recovery and quirks mode, a CSS engine with the cascade, specificity and layers, a layout engine covering the box model, floats, the full Flexbox and Grid algorithms, and paint and composite with stacking contexts, layer promotion and a basic scanline rasterizer.

### Is there any code in the raw-bits-to-react repository?

No. The repository contains a single readme.md, so it is a syllabus rather than an implementation, and everything described in the plan is something the reader would build themselves.

## Sources

- [Issues](https://github.com/renderffx/raw-bits-to-react/issues)
- [README](https://github.com/renderffx/raw-bits-to-react/blob/main/README.md)
- [renderffx/raw-bits-to-react on GitHub](https://github.com/renderffx/raw-bits-to-react)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/renderffx-raw-bits-to-react