JavaScript projects: A Practical Course with Kai Nakamura

Start with the purpose

Place JavaScript projects inside a small but realistic software or digital-safety task. Name the result a learner is trying to produce and the constraints that make the skill useful.

How JavaScript projects actually works

These are the load-bearing ideas. Everything later in the course is an application of one of them, so it is worth reading slowly and returning to when something stops making sense.

• Loose equality coerces types first. The == operator converts its operands before comparing, which is why 0 equals an empty string under it while NaN never equals itself. Default to the strict === and !== operators, and use == only for the deliberate null-or-undefined check.
• Microtasks run before the next macrotask. Promise callbacks queue as microtasks, and the whole microtask queue drains after the current synchronous code finishes but before any timer callback runs. That is why a resolved promise callback fires ahead of a setTimeout with a delay of zero.
• Numbers are IEEE 754 doubles. Every JavaScript number is 64-bit floating point, so 0.1 + 0.2 evaluates to 0.30000000000000004 and integers beyond about 9 quadrillion lose precision. Handle money in integer minor units such as cents, or use BigInt for large exact integers.

Misconceptions worth clearing early

Each of these is common, understandable, and expensive to leave in place. Recognising them now saves rework later.

• Expecting an async function to return its value directly. The body reads like ordinary sequential code, so the return looks ordinary too. Fix: An async function always returns a promise. Await the call, or chain a then handler onto it.
• Losing the value of this when passing a method as a callback. The method reference is handed over without its receiver object attached. Fix: Wrap it in an arrow function or bind the method, since arrow functions take this from the enclosing scope.
• Changing several things at once when something breaks. It feels faster than testing one change at a time. Fix: Change one thing, observe, and revert it if the behaviour does not move; keep the loop small.

Build the mental model

Connect the key terms as a process rather than a word list. Use this sequence: decompose the problem, build one testable step, inspect the result, and debug deliberately.

Catch the common miss

Compare a surface-level attempt with one that shows correct behavior, readable structure, useful tests, and an explained decision. Explain the single difference that matters most.

Watch the whole process

Trace a model from the initial prompt to a working program, configuration, or technical walkthrough. Mark each point where the learner must observe, choose, or verify rather than act automatically.

Worked example: Predicting the output order of an event-loop snippet

Follow each step and predict the next before you read it. Predicting first is what turns a demonstration into practice.

1. A script logs A, then schedules a timer logging B with zero delay, then a resolved promise logging C, then logs D directly.
2. The synchronous statements execute first in source order, printing A and then D.
3. The call stack empties, so the microtask queue drains next and prints C.
4. Only afterwards does the event loop pick up the timer macrotask and print B, giving the order A, D, C, B.

A setTimeout of zero does not mean immediately; it means after the current task and after every pending microtask.

Where this usually goes wrong

Watch for these while you work through the demonstration rather than afterwards.

• Expecting an async function to return its value directly. The body reads like ordinary sequential code, so the return looks ordinary too. Fix: An async function always returns a promise. Await the call, or chain a then handler onto it.
• Losing the value of this when passing a method as a callback. The method reference is handed over without its receiver object attached. Fix: Wrap it in an arrow function or bind the method, since arrow functions take this from the enclosing scope.
• Changing several things at once when something breaks. It feels faster than testing one change at a time. Fix: Change one thing, observe, and revert it if the behaviour does not move; keep the loop small.

Practice with scaffolding

Repeat the model with one detail changed. Keep the prompts visible and say or write the reason for each choice before continuing.

Check before feedback

Use correct behavior, readable structure, useful tests, and an explained decision as the quality test. Make one self-correction before asking the tutor to review the result.

Read the situation

Translate the scenario into a clear task. Separate facts, assumptions, constraints, and information that is interesting but not relevant to Creative coding.

Choosing well under real constraints

Applied work is mostly judgement under limits: less time, less information, and more competing goals than a textbook example allows. These are the decision rules that hold up in practice.

• Two approaches both look workable: Choose the one you can test more easily; testability compounds faster than elegance.
• The task feels too large to start: Cut it until one piece can be finished and verified in under an hour, then build outward.
• You are unsure whether something is a real bug: Write the smallest input that reproduces it; if you cannot reproduce it, you cannot claim to have fixed it.

Reading the situation before acting

Before choosing an approach, state three things explicitly: what result the situation actually requires, which constraints are fixed rather than preferences, and what evidence would tell you the approach is working. Skipping this step is the most common reason competent work solves the wrong problem.

• Loose equality coerces types first. The == operator converts its operands before comparing, which is why 0 equals an empty string under it while NaN never equals itself. Default to the strict === and !== operators, and use == only for the deliberate null-or-undefined check.

Practitioner notes

Small pieces of working knowledge that rarely appear in introductory material.

• Prefer const, fall back to let, and treat var as legacy. Block scoping alone eliminates an entire class of loop-closure bugs.
• Use map, filter and reduce when transforming data, but keep a plain for loop when you need to break early or the transformation is genuinely imperative.

Compare real options

Generate two workable approaches and test both against the purpose. Do not hide the tradeoff; name what each option improves and what it gives up.

Make the reasoning visible

Produce a working program, configuration, or technical walkthrough and attach a short decision note. The note should make the result auditable, not merely confident.

Use the rubric, not a feeling

Review the work for correct behavior, readable structure, useful tests, and an explained decision. Record evidence for each judgment so feedback points to something observable.

Diagnostic checklist

Run this before you revise anything. Diagnosing first prevents the common failure of polishing the parts that were already fine.

• Check: Expecting an async function to return its value directly — is this present in your work?
• Check: Losing the value of this when passing a method as a callback — is this present in your work?
• Check: Changing several things at once when something breaks — is this present in your work?
• Check: Reading code without running it — is this present in your work?

The quality bar

This is what finished work looks like in this field. Use it as the standard for your revision rather than a general sense of improvement.

• The behaviour is correct on ordinary input and on at least one awkward edge case
• Names describe intent, so the code can be read without the author present
• There is a concrete way to demonstrate that it works, not just an assurance

Diagnose before editing

Name the symptom, then ask what decision or missing step produced it. Choose the cause you can address rather than changing everything at once.

Revise and compare

Make one purposeful revision and compare the two versions. Keep the change only if it improves the intended result without creating a larger problem.

Define a finishable brief

Choose a specific audience, result, and boundary for the Portfolio polish capstone. Reduce scope until the project can be finished and reviewed in one focused cycle.

Bringing the parts together

A capstone is judged on coherence, not on the number of techniques it includes. Return to the core ideas and make sure the work demonstrates them rather than decorating them.

• Loose equality coerces types first. The == operator converts its operands before comparing, which is why 0 equals an empty string under it while NaN never equals itself. Default to the strict === and !== operators, and use == only for the deliberate null-or-undefined check.
• Microtasks run before the next macrotask. Promise callbacks queue as microtasks, and the whole microtask queue drains after the current synchronous code finishes but before any timer callback runs. That is why a resolved promise callback fires ahead of a setTimeout with a delay of zero.
• Numbers are IEEE 754 doubles. Every JavaScript number is 64-bit floating point, so 0.1 + 0.2 evaluates to 0.30000000000000004 and integers beyond about 9 quadrillion lose precision. Handle money in integer minor units such as cents, or use BigInt for large exact integers.

Standards that make the work credible

These are the marks of work that would be taken seriously by someone who does this professionally.

• The behaviour is correct on ordinary input and on at least one awkward edge case
• Names describe intent, so the code can be read without the author present
• There is a concrete way to demonstrate that it works, not just an assurance

Practitioner notes

Small pieces of working knowledge that rarely appear in introductory material.

• Prefer const, fall back to let, and treat var as legacy. Block scoping alone eliminates an entire class of loop-closure bugs.
• Use map, filter and reduce when transforming data, but keep a plain for loop when you need to break early or the transformation is genuinely imperative.

Build with checkpoints

Plan foundation, first draft, verification, and revision milestones. At each checkpoint, save evidence instead of relying on memory.

Present and continue

Present a working program, configuration, or technical walkthrough with a concise rationale. Use the final rubric to choose one strength to retain and one next practice target.