Live Instruction · JavaScript · Closures · Masterschool
JavaScript Closures —
Live Practice Session
Two live sessions working through JavaScript closures — from functions returning functions and the setTimeout loop bug, to advanced stateful problems: a Hobby Tracker with cumulative cache and a Censor function that swaps words in any sentence. Audience participation throughout.
The Session
Start simple. Get real.
Closures are one of those JavaScript concepts that students hear about constantly before they understand them. The word shows up in interviews, documentation, and error messages — but until you write a few yourself and watch them work, the mental model doesn't stick. These two sessions were built around doing exactly that: writing closures live, together, with increasing complexity, and pausing to explain what was actually happening at each step.
The first session started with the simplest possible closure and progressed through DOM events and the classic setTimeout loop bug. The second session went further — two open gym problems that required closures to do real stateful work: a Hobby Tracker that accumulates hours per hobby in a cache object and resets on demand, and a Censor function that stores word replacement pairs and swaps them in any sentence using Object.keys() and String.replace().
Students participated via chat throughout — raising their hands, asking questions about syntax, and testing the code live. The first session ran with the Pomodoro technique; the second was open gym format with two structured problems.
4
progressively harder problems
Masterschool Coding Bootcamp
JavaScript · Closures · Udacity Curriculum
International cohort · Live Q&A format
The Content
What the sessions covered
Six live coding problems across two sessions — from basic closures to stateful cache objects and string replacement.
First-Class Functions
Established the conceptual foundation — in JavaScript, functions can accept other functions as parameters or return them as results. Used the term "first-class functions" and connected it to why closures are possible in the first place.
Closures: Return a Function
Started with the simplest closure — a function that creates and returns another function that returns "hello world." Walked through the syntax live with student input, then called and logged the result to confirm it worked.
Closures with Input
Extended the first example to accept a string argument — showing how the inner function retains access to the outer function's scope even after the outer function has returned. The core mechanic of closures made visible.
DOM Manipulation with Closures
Wired closures to click events to change font size dynamically — toggling between sizes 24, 44, and 56 — demonstrating how closures can remember and manage state in a real browser context.
The setTimeout Loop Bug
Demonstrated the classic setTimeout loop problem — where every iteration logs the same value because the loop finishes before the callbacks fire. Fixed it first with a closure, then refactored to an IIFE and explained the difference.
Lexical Environment & IIFEs
Explained lexical environment in plain terms — the inner function captures the value of i at the moment the outer function runs, not when the callback fires. Connected IIFEs as an alternative syntax for encapsulating that scope.
Hobby Tracker — Cache & Accumulation
Built a closure that takes an array of hobbies, initializes a cache object with each as a key set to zero, and returns a function that accumulates hours per hobby. Calling it with no arguments resets all values and returns a confirmation string.
Censor — Stored Replacement Pairs
Built a closure that stores word replacement pairs (dogs→cats, quick→slow) in an internal object. When called with a sentence, it loops through stored keys using Object.keys() and forEach, applying String.replace() for each pair.
Stateful Closures in Practice
Both problems in the second session demonstrated the same core pattern — a closure holding onto private state (a cache object) that persists across multiple calls. The inner function reads and mutates that state without exposing it.
The Approach
Progressive difficulty with live student participation
The session was deliberately structured to build toward complexity rather than introduce it all at once. Closures are easy to define and hard to internalize — the definition ("a function that retains access to its outer scope") doesn't land until you've seen the behavior. Starting with the simplest possible example and then asking students to predict what happens next gives the concept somewhere to attach.
Student participation was built into the structure. Instead of walking through each solution, I read out the problem, gave students time to think, and invited responses via chat and raised hands. When a student started answering correctly — "create function, parentheses, curly braces" — I coded exactly what they said, live, which kept the session collaborative rather than a lecture.
The setTimeout example is the most important one in the set. It's the problem that makes closures click for most students because it's a real bug that has a real consequence — and fixing it requires understanding what closures actually do. Walking through the broken version first, then diagnosing it, then fixing it with a closure, and then refactoring to an IIFE gives students three different views of the same concept.
The session closed with a look ahead — upcoming sessions would include a test suite so students could work through problems in pairs and verify their own solutions, moving the format closer to a workshop.
Scaffold from Simple
Function → returns function → returns string
Add Complexity
Input arguments → closures capture outer scope
Make It Real
DOM events → click to change font size
Fix a Classic Bug
setTimeout loop → closure fix → IIFE refactor
Name the Concepts
First-class functions · lexical environment · IIFE
Session Recording — Part 1
First-Class Functions to setTimeout
Basic closures, DOM events, and fixing the classic setTimeout loop bug with closures and IIFEs.
Session Recording — Part 2
Hobby Tracker & Censor
Two advanced open gym problems — stateful cache objects and string replacement with stored closure pairs.
Reflection
Why the broken version comes first
The pattern I kept coming back to in this session — show the broken version before the fix — is one of the most effective things you can do when teaching a concept that's easy to memorize and hard to understand. If students only ever see working closure code, they don't develop an intuition for why closures exist. The setTimeout bug is a perfect teaching case because the broken behavior is surprising and the fix is satisfying.
What this session reinforced is that closures aren't really a single concept — they're a cluster of related ideas (scope, first-class functions, lexical environment, IIFE syntax) that only make sense together. Introducing them through a sequence of problems, rather than a definition followed by examples, lets students build the mental model piece by piece.
3
views of the same concept
Closure fix · IIFE refactor · lexical scope
Broken first · diagnose · fix
setTimeout · forEach · DOM events
Keep Exploring
Related Case Studies
Interested in working together?
I'm open to remote opportunities in technical learning experience design, developer education, and customer enablement.