A frontend engineer runs more algorithms than they write: every frame the browser matches selectors, breaks lines, sizes flex tracks, culls paint, and the engine walks transition trees and marks heaps. Knowing those algorithms is what turns "it is slow" into "it is O(n²) here, and here is the n". This module is the algorithms you write for a UI and the ones the platform runs underneath, each with its complexity, its data structure, and a measurement.
First, where complexity actually bites in an interface, with numbers. Then the algorithms you own: debounce and throttle, windowing, list diffing, caches, search and ranking, sorting at UI scale, graph traversal, priority scheduling. Then the platform's: the CSSOM, layout, paint, the schedulers, V8, reconciliation, compilers, and text processing, each drawn step by step.
where it bitesThe sizes a UI actually has, and which algorithm goes quadratic at those sizes.
you writeDebounce, virtualisation, diffing, LRU, search, sort, graphs, priority queues: each with code and a cost.
the CSSOMSelector matching right to left, the bloom filter, invalidation sets as set algebra.
layoutBlock, inline and line breaking, the flex algorithm, grid track sizing, tables: the actual steps.
paint and schedulePaint order, display list culling, tiling and damage; the event loop and React lanes as scheduling problems.
the engineTransition trees, inline cache lookup, generational and incremental GC as algorithms.
reconciliation and compilersReact's O(n) heuristic diff; tokenising, Pratt parsing, SSA, DCE, register allocation, tree shaking.
textUTF-8 decoding, grapheme segmentation, bidi, hyphenation, fuzzy matching.
Every chapter has a costEach algorithm comes with its complexity, the data structure it needs, the sizes at which it matters in a UI, and the sibling course where the mechanism lives (the browser course for the pipeline, the JS course for the engine).