DSA for Frontend

Big-O reasoning grounded in frontend scenarios — nested loops over rendered lists, .includes() in a loop, space complexity, and why constants and real data size matter more in practice than in theory.

1. 1Why Big-O Matters for Frontend Code9 minBig-O is not academic trivia — it is the difference between a filter that feels instant and one that freezes the tab once a real customer's data shows up.
2. 2Time Complexity and Amortized Cost10 minHow to actually derive a Big-O by counting operations rather than guessing, and why array.push() is called O(1) even though it occasionally does much more work.
3. 3Space Complexity, and Why Constants Matter in Practice9 minMeasuring auxiliary memory the same way you measure time, why recursion has a hidden space cost, and why real data size and constant factors often decide more than the asymptotic class.

Two pointers, sliding window, in-place manipulation, prefix sums, and the string parsing and validation problems that actually show up in frontend code.

1. 4Two Pointers10 minSolve array and string problems in one linear pass by walking two positions at once — reversing in place, detecting palindromes, and merging sorted data without extra memory.
2. 5Sliding Window10 minAvoid recomputing overlapping work by growing and shrinking a window over an array or string in one pass — fixed-size sums, longest-substring problems, and a real debounce framing.
3. 6In-Place Array Manipulation9 minMove, remove, and compact array elements without allocating a second array — the read/write pointer technique behind moving zeroes, removing values, and rotating a list.
4. 7Prefix Sums for Fast Range Queries8 minPrecompute running totals once so any range sum — a dashboard's "total between two dates," a list's visible-region total — answers in O(1) instead of re-summing every time.
5. 8Parsing and Validating Strings10 minReal frontend string problems worked as algorithms — balanced brackets for a code editor, tokenizing a template string, and why a validation regex is a state machine wearing a disguise.

Hash maps and sets for O(1) lookup, frequency counting, the two-sum pattern, and grouping and deduplicating with a map.

1. 9Hash Maps and Sets for O(1) Lookup10 minWhy Map and Set turn "is this here?" from a linear scan into a constant-time answer, what makes that O(1) claim true, and real gotchas — object keys, NaN, and reference equality.
2. 10Frequency Counting with Maps8 minCount occurrences once with a map instead of re-scanning for every distinct value — anagram checks, "most common tag," and duplicate detection, all in one linear pass.
3. 11The Two-Sum Pattern8 minThe single most-asked interview problem, worked properly with a hash map in one pass — and a real frontend framing, matching a cart's line items against a target discount threshold.
4. 12Grouping and Deduplicating with Maps8 minTurn a flat list into groups, and remove duplicate objects by a key rather than by reference — the two map-based transforms behind almost every "shape this API response" task.

What actually happens on the stack, recursion versus iteration, stack overflow risk with deep trees, memoization as a bridge to dynamic programming, and divide and conquer.

1. 13Recursion and the Call Stack9 minWhat actually happens on the call stack when a function calls itself — base cases, recursive cases, and tracing frames by hand until the mechanism stops feeling like magic.
2. 14Recursion vs. Iteration, and Stack Overflow Risk9 minWhy a recursive function that works perfectly in every test can crash in production on deeply nested real-world data — and the explicit-stack technique that removes the risk entirely.
3. 15Memoization, and a Taste of Dynamic Programming10 minWhy naive recursive Fibonacci is exponential, how caching subproblem results fixes it, and just enough dynamic programming vocabulary to recognize the pattern when it shows up.
4. 16Divide and Conquer, with Merge Sort10 minSplit a problem in half, solve each half recursively, and combine the results — the strategy behind merge sort, and the proof of why it's O(n log n) rather than O(n²).

Binary trees, BFS and DFS traversal, the DOM as a tree, and the real frontend problems that are secretly tree problems — flattening comments, file trees, and searching a component tree.

1. 17Binary Trees and Tree Vocabulary9 minThe vocabulary every tree problem is described with — root, leaf, depth, height, balance — and why a binary search tree's O(log n) promise depends entirely on staying balanced.
2. 18Tree Traversal: BFS and DFS10 minTwo different ways to visit every node in a tree — breadth-first with a queue, depth-first with recursion or a stack — and how to actually decide which one a problem calls for.
3. 19The DOM Is a Tree9 minEvery DOM API you already use is a tree traversal wearing a familiar name — querySelectorAll, closest(), contains() — and knowing which to reach for is a real complexity decision.
4. 20Flattening Nested Comments and Building a File Tree10 minTwo common frontend tasks are secretly the same tree algorithm run in opposite directions — collapsing a nested reply thread into a flat list, and rebuilding a tree from flat data.
5. 21Searching a Component Tree9 minFinding a node by id, computing a breadcrumb path, and collecting every match in a rendered component tree — real tree-search problems disguised as UI features.

Linked lists with real frontend framing, stacks and queues in real UI code, and an LRU cache built from a map and a doubly linked list.

1. 22Linked Lists: The Frontend-Relevant Parts9 minWhy arrays beat linked lists for almost everything in JavaScript — and the real situations (undo history, an LRU cache) where the linked list's O(1) insertion actually earns its keep.
2. 23Stacks and Queues in Real UI Code8 minLIFO and FIFO are not abstract vocabulary — they're the exact discipline behind undo history, browser navigation, toast notification order, and a print or upload queue.
3. 24The LRU Cache, with a Map and a Linked List11 minBuild a genuinely O(1) least-recently-used cache — the structure behind a bounded memoization layer, an image cache, or any "keep the N most recently used things" feature.

Enough graph theory to recognize a graph problem and run BFS/DFS on an adjacency list — dependency graphs, friend-of-friend problems, and cycle detection.

1. 25Graphs as Adjacency Lists, and BFS/DFS10 minA tree is a graph with extra rules — drop them, and BFS/DFS still work almost unchanged, on dependency graphs, friend-of-friend recommendations, and module import graphs.
2. 26Cycle Detection and Topological Order10 minDetecting a circular import before it crashes your build, and computing a valid build order for dependent tasks — both answered by one graph-coloring DFS technique.

When the built-in sort is enough and when it isn't, binary search, and the search-on-answer pattern that applies it beyond a sorted array.

1. 27When the Built-In Sort Is Enough (and When It Isn't)9 minArray.prototype.sort's real complexity and stability guarantees, the comparator mistakes that silently corrupt results, and the rare, genuine reasons to reach for something else.
2. 28Binary Search, and the Search-on-Answer Pattern10 minBinary search proved properly, plus its most underrated form — searching over a range of possible ANSWERS rather than a sorted array, for problems that don't look like search at all.

Two capstones applying DSA to genuine frontend problems: debouncing and throttling analyzed with the right complexity framing, and why virtualizing a list is an algorithmic problem, not just a rendering trick.

1. 29Debouncing, Throttling, and the Right Complexity Framing10 minDebounce and throttle look like timer tricks, but the sliding-window model from earlier in this course explains their guarantees — and a naive implementation's real bugs.
2. 30Virtualizing a List as an Algorithms Problem11 minThe final capstone — why rendering a 100,000-row list is an O(n)-versus-O(visible) algorithms problem in disguise, and how binary search finds the right starting row in O(log n).