Back to learning
JavaScript

JavaScript Foundation

Make a page do something. Start with one line the browser runs and finish with a task tracker you built, debugged and can explain.

  • Beginner
  • About 8 weeks
  • 6 milestones
  • 26 steps
HTMLJavaScript
Start this journey
What you will have builtA Personal Task Tracker you wrote yourself, and the habit of reading what the browser tells you when something breaks.Start this journey

What this asks of you

Every figure below is read from the journey itself, not written about it.

BeginnerNo prior experience needed
About 8 weeksAn estimate, not a deadline
6 milestonesEach one claims a capability
26 stepsShort, and every one is built

What you will be able to do

Every milestone claims one engineering capability. You reach it by building something, not by finishing a chapter.

JavaScript Enters the WebConnect a JavaScript file to a page, prove the browser runs it, keep and inspect values by name in the console, and use an error message to find and fix what brokeEvery later milestone assumes the learner can make the browser run their code, see what it did, and read what it says when it fails. Without that, each error is a dead end instead of a clue
4 steps
Show the 4 steps
  • The tracker gets a program

    Connect a JavaScript file to a new page and prove the browser ran it.

  • The console speaks and listens

    Use the console to report what your program is doing, and to ask the browser questions directly.

  • The tracker remembers

    Keep the tracker’s first facts in named variables, and use the names instead of repeating the values.

  • Someone else's first attempt

    Use the browser’s error messages to find and fix the faults in a short script you did not write.

Programs Store, Calculate and DecideCompute a result from values, predict when JavaScript will convert a type and what it will produce, and turn a stated rule into a condition tested at its boundary valuesA program that can only hold what you typed cannot tell you anything you did not already know. This is where the tracker starts working things out — and where a fault first appears with no error message attached, only a wrong answer
4 steps
Show the 4 steps
  • The tracker works it out

    Replace the tracker's typed-in facts with values the program calculates from what it already knows.

  • When JavaScript changes your values

    Predict what JavaScript does when a number and some text meet, and convert values on purpose instead of hoping.

  • The tracker decides

    Turn the tracker’s stated rules into conditions, and check them at the values where they break.

  • A rule that gives the wrong answer

    Find and fix a fault in a rule you did not write, in a program that produces no error at all — only a wrong answer.

Programs Repeat and Reuse LogicRepeat work with a loop that runs the right number of times, package a rule as a function that takes inputs and returns a result, and replace duplicated logic with one function while showing it still gives the same answersA program that repeats itself has to be changed in every place it repeats, and one of them always gets missed. This is where a rule gets one name and one home — and where you prove that a rewrite changed nothing but the shape
4 steps
Show the 4 steps
  • The tracker draws its progress

    Draw the tracker’s progress as a bar, one character for every planned task, built by a loop that runs exactly as many times as it should.

  • One rule, one home

    Give the tracker’s repeated decision one name and one home: a function that takes a task and returns the line to show for it.

  • The tracker asks its own functions

    Move the tracker’s count and its bar into functions that return them, and prove the rewrite changed nothing the tracker says.

  • A function that gives nothing back

    Find and fix a function you did not write that shows its answer instead of handing it back, in a program with no error at all — only the word undefined.

Programs Work With Real DataRepresent a collection as an array of objects, answer questions of it with array methods, and choose the shape of a record and defend itValues that belong together drift apart when they are kept apart, as the tracker just showed. This is where the program holds its data as records and asks the data, instead of being told
4 steps
Show the 4 steps
  • The tracker walks its tasks

    Hold the tracker’s task titles in one array, take the planned count from it, and print every title as a numbered list with one loop.

  • Each task becomes one thing

    Turn every task into one record that holds its id, its title and whether it is done, keep the records in one array, and count what is done from the records themselves.

  • The tracker asks questions of its list

    Answer the tracker’s questions with filter, find and map inside functions that take the list, prove the rewrite changed nothing, and show that one change to the data updates every output.

  • The record that is not there

    Diagnose a program whose find returns undefined, starting from an error that names a different line, and fix it by changing only the line where the value went wrong.

JavaScript Controls the BrowserMake the page respond to its user: read form input, refuse invalid input with a useful message, update the data and redraw the page from it, and choose between redrawing from data and patching elements, and say whyThe program knows everything about its tasks, the page knows none of it, and nobody but the author can change them. This is where the page shows the data, answers a click and accepts a task from someone else
5 steps
Show the 5 steps
  • The page shows what the program knows

    Put the tracker’s summary, progress line and status on the page, and mark the summary with a class when every task is done, leaving its look to the stylesheet.

  • The list is drawn from the data

    Write one render function that works out every count and draws the whole page from the tasks, and show that the page changes only when something draws it.

  • The page answers a click

    Give every task a button that marks it done or not done and one that deletes it, and give the page filters, where every click changes the data and then redraws.

  • Someone else adds a task

    Let anyone add a task through a labelled form without the page reloading, refuse a title that is empty or only spaces with a message, and give every new task an id no other task has.

  • The element that is not there yet

    Diagnose a page whose script finds nothing, starting from an error in app.js, and fix it by changing only the file where the cause is.

Build and Improve an Interactive ApplicationKeep an application’s data across visits, refuse input that does not fit, absorb a changed requirement, find and fix faults in a version you did not write, and explain the decisions and a limitation of your own workThe tracker does what its user asks until they reload, and has only ever changed to its author’s own plan. This is where it keeps its data, meets a request that arrives late and a program someone else broke, and is published and defended
5 steps
Show the 5 steps
  • The tracker keeps what its user did

    Store the tasks after every change and load them once when the page starts, so a reload shows what its user did — including on a first visit, when nothing has been stored yet.

  • Refuse what does not fit

    Refuse a title longer than 60 characters, and a title already in the list, each with its own message — comparing trimmed, lowercase titles with some — and decide and record whether a task already done counts.

  • A request arrives after the tasks are stored

    Give every task a priority, normal or high, switched by a button on the task — and decide, make work and explain what happens to the tasks stored before priority existed.

  • A tracker someone else wrote

    Find and fix three faults in a supplied tracker from its owner’s report, and write a diagnosis record for each: symptom, reproduction, hypotheses with their evidence, cause, fix and verification.

  • Ship the tracker and explain it

    Publish the finished tracker, meet it at its public address as a first visit, and write the design explanation: two decisions with what they rejected, and one limitation of your own work.

How the work is verified

  1. ReadThe context you need for this step, and why it matters. Never more than that.
  2. BuildYou produce something real. The work is yours, in your own repository.
  3. SubmitYou send it, with a note on what you chose and what you were unsure about.
  4. ReviewA senior engineer reads it and responds. They may ask for changes — that is the normal path through engineering review, not a failure.
  5. VerifiedThe capability is confirmed, it goes on your record, and the next step opens.

How you want to work

You choose when you start. Both cover the same journey and the same definition of done.

Mentor guidedReviewed by a person

A senior engineer is assigned to you. They read every submission, respond in writing, and decide when a capability is verified. Expect to be asked for changes.

Self pacedVerified by you

You work through the same journey and verify your own work against the same definition of done. Nothing is submitted to anyone, and nothing waits on anyone.

What you end up with

Counted from this journey, not described in general.

A Personal Task Tracker you wrote yourself, and the habit of reading what the browser tells you when something breaks.Built by you, in your own repository.
6 verified capabilitiesEach one confirmed against its definition of done, with the name of whoever confirmed it. There is no certificate. The work is the credential.

Ready to start JavaScript Foundation?

You will choose how you want to work on the next screen. Nothing starts until you confirm it. You can run several journeys at once, and each one is mentor-guided or self-paced on its own.

Start this journey