Understand the idea
Start with a real question
Suppose a study app tells you that three sessions of twenty minutes equal "320" minutes. The program ran. It printed a result. Yet the result is not the calculation you intended. That is a valuable first programming puzzle: running successfully and answering the right question are different things.
JavaScript will let us store the inputs, perform a calculation and inspect the result. We will begin in the output panel rather than immediately building buttons or fetching data. Keeping the program small makes its decisions visible. You can point to the exact instruction that produced an unexpected value.
Before running each example, write down what you expect to see, including whether the result is text or a number. A surprising output is not a failed lesson. It is an opportunity to replace a guess with a mental model you can use again.
Understand the idea
JavaScript turns instructions into behaviour
JavaScript is a programming language used to calculate values, make decisions and respond to events. In a browser project, HTML supplies structure, CSS supplies presentation and JavaScript supplies programmable behaviour. The language can also run in other environments, so do not assume that every JavaScript program has a web page to manipulate.
This first lesson uses console mode. The practice runtime is isolated from the main website and prints output from console.log. It is not an unrestricted browser tab. Do not use external packages, network requests, alert, prompt or browser storage here. A later lesson introduces the separate Interactive DOM preview and its supported interfaces.
See how it works
Example 1: print an exact message
JAVASCRIPT exampleRead the code, then try a change.
Try this example
console.log("Ready to practise");
console.log("Read, predict, run, compare");
Expected output:
ReferenceCompare this with the explanation.
Ready to practise
Read, predict, run, compare
The quoted text is a string value. Its quote characters delimit the value; they do not appear in this output. Parentheses contain the value passed to console.log, and the dot accesses log on console. Each call writes its message to the output panel. Here, the semicolon marks the end of an instruction. JavaScript can insert some semicolons automatically, but explicit consistent punctuation is useful while learning.
See how it works
Example 2: compare numbers with numeric-looking text
JAVASCRIPT exampleRead the code, then try a change.
Try this example
console.log(12 + 3);
console.log("12" + "3");
console.log(12 * 3);
Expected output:
ReferenceCompare this with the explanation.
15
123
36
The first expression adds two numbers. The second joins two strings; quotation marks change the kind of value, even though the characters look numeric. The multiplication operator is an asterisk. Expressions are evaluated before their results are printed. Be precise about value types rather than relying on what a value looks like on screen. Later lessons cover conversion and the additional behaviours of operators in detail.
See how it works
Example 3: give values useful names
JAVASCRIPT exampleRead the code, then try a change.
Try this example
const price = 150;
const quantity = 2;
const total = price * quantity;
console.log(total);
Expected output:
ReferenceCompare this with the explanation.
300
const declares a binding with a name. The equals sign supplies its initial value; it is not an equality comparison. Read the instructions from top to bottom: price receives 150, quantity receives 2, and total receives the calculated product. Printing a name reads the value associated with it.
Use meaningful names such as quantity, not an unrelated label chosen only to shorten typing. JavaScript distinguishes uppercase and lowercase letters, so Price and price are different names. A const binding cannot be reassigned. Future lessons compare const with let and explain what this rule does and does not imply for objects.
Spot the mistake
Errors provide clues
An unmatched quote or missing closing parenthesis can produce a syntax error before the intended output appears. Reading a name that has not been declared produces a different kind of error. Neither means that you should replace the whole program. Read the message, inspect the indicated area and compare the source against the intended instruction.
Try changing quantity to 4 in Example 3. Predict 600 before running it. Then change only the final call to console.log(price). Predict 150: declaring total does not change the original price. This small experiment separates calculating a new value from changing an existing one.
Your turn
Independent exercise
Write a program that declares a ticket price and a ticket count, calculates a total and prints it. Add a separate printed heading describing the calculation. Use only numbers, strings, const, multiplication and console.log; do not introduce input boxes or DOM operations yet.
Show hint Start with two constant declarations. Give the product its own name before printing it, so each step has a clear purpose.
Show solution For example, const ticketPrice = 200; const ticketCount = 3; const ticketTotal = ticketPrice * ticketCount; followed by console.log("Ticket total"); and console.log(ticketTotal); prints a heading and then 600. Different sensible names and values are valid.
See how it works
Trace a value before trusting its appearance
A console displays characters, but the program operates on values with types. The same digits can be a number in one expression and a string in another. Read the quotation marks in the source before predicting what + will do. Named results are also values, not live spreadsheet formulas. The program calculates the expression at the moment that instruction executes. Reading an input binding to calculate a new total does not change that input binding. Keep those ideas separate when debugging an unexpected result.
Understand the idea
Slow down at the important part
Understand the idea
Separate the value from the way it is displayed
A value can be a number or a string containing digits. Those values may look similar when printed, but their behaviour in an expression can differ. Look at the literal syntax and the operator together. Quotation marks are a decision about the kind of value, not a decoration around a number.
When a result surprises you, locate the expression that produced it before changing the display statement. If an expression joined text, making the output label prettier will not turn that earlier result into numeric arithmetic. Trace the inputs, then the operation, then the display.
Understand the idea
Names help you explain a calculation
Imagine explaining your program to a classmate who has not seen it. A name such as minutesPerSession gives them a clue about the value's role. A name such as x may be valid, but forces them to reconstruct the meaning from every use. Clear names reduce the amount of detective work a reader must do.
Keep inputs and a calculated result separate in the first program. This gives you checkpoints: confirm the inputs, predict the multiplication, then inspect the total. Combining everything into a single long expression is not automatically more advanced. Often it simply makes the first incorrect assumption harder to find.
Understand the idea
Reassignment is not automatic recalculation
An assignment runs when execution reaches it. A calculated total records the value produced at that point. Changing an input later does not ask the earlier expression to execute again. To obtain a new total, the program needs another calculation.
This explains a common puzzle in the examples: two names that were related during one calculation do not become permanently linked spreadsheet cells. Read the instructions in order and keep a small paper record of the current values. You will use this same habit when programs eventually contain conditions, functions and user events.
Your turn
Build it, change it, explain it
Plan three study sessions with a numeric duration per session. Name both inputs, calculate a separate total and print a clear label with the result. Before running, predict the exact total yourself. Then change only one input and recalculate.
For the next experiment, put a new assignment to an input after the total has already been calculated. Predict the old total and the new input separately. Run once, then add the recalculation and compare the outputs. Explain which instruction changes the result, not merely which number changed on the screen.
Finish by changing one numeric input into a quoted string and examining the expression carefully. Do not rely on an accidental coercion as your explanation. State what kinds of values your program is supposed to accept and why those kinds fit the calculation.
Understand the idea
What this makes possible
You have begun the most reusable programming habit: predicting a result, observing it, and explaining the first point where the two disagree. Keep that habit as the language grows. More syntax is useful only when you can still reason about what your program does.