Writing an Application

A language is a set of words a computer has been taught to obey. Structure is written in HTML, style in CSS, behaviour in JavaScript. They are separate because they answer separate questions, and because keeping them separate means you can change how something looks without any risk of breaking what it does.

This course is almost entirely about the third one. Behaviour is where the thinking lives, and it is the part that transfers: the ideas in the next thirteen steps are the same ideas in Python, in Java, in the language running inside a washing machine.

It is this page's word. JavaScript itself has no say. What a browser actually gives you is console.log("hello"), which writes a line into a panel called the console that you only see if you go looking for it. Everything else about the line is exactly real: the name of the job, the round brackets holding the material, the quotes, and the fact that it is carried out precisely as written.

The page uses say because output should be visible without a detour, and because the name says what it does. When you open a real browser console later, write console.log instead and everything you learned here still holds. A few more page words turn up as you go: ask() for reading the box on the page in Step 4, and load() and save() for the cupboard in Step 12. Each one stands for something a browser really does, and each is pointed out when it arrives.

The round brackets mean "do this, using what is inside". say("hi") is one instruction: the name of the job, then the material to do it with. Without brackets, say is just the word, in the same way that "kettle" is not the same as boiling one.

The quotes mean "the letters inside here are text, not an instruction". "hello" is five letters. hello with no quotes is a name, and the computer will go looking for something called hello and complain when there is nothing there. You will meet that error in a moment, on purpose.

An error is not the computer telling you off. It is the computer stopping at the first thing it could not carry out and telling you where it stopped. It always includes a line number, and the line number is almost always right, even when the actual mistake is a missing bracket on the line above.

Read it in this order: which line, then what word it is complaining about, then what it says it expected. Three quarters of all errors you will ever see are a misspelled name, a missing bracket, or missing quotes.

In maths, x = 5 is a statement about the world that is either true or false. In a program it is an instruction: put 5 into x. It is an arrow pointing right to left, and it is always an order, never an observation.

That is why score = score + 10 makes sense here and would be nonsense in maths. Work out the right-hand side first, using the current contents of the box, then put the answer back in the same box. If score held 30, the right side works out to 40, and 40 goes in.

Both make a labelled box with something in it. let makes one you are allowed to refill later, which is why let score = 0 followed by score = 100 is fine. const makes one that keeps whatever you first put in, and trying to refill it stops the program with the message "was made with const, so its value cannot be changed".

Use let for a box whose contents change, like a score. Use const for one that should not, like a list of quests that stays the same list all the way through. One catch worth knowing before Step 7: a const list can still have things added to it and taken out of it. What cannot change is which list the name refers to, not what is inside that list.

A name may use letters, numbers and underscores, and may not start with a number. Beyond that the computer does not care in the slightest: x, score and currentPointsThisRound are all equally valid.

The people who care are you, next week. A name is a note to your future self about why this box exists. Two words joined with a capital in the middle, like totalPoints, is the usual habit in JavaScript. None of this affects whether the program runs, which is exactly why it gets forgotten.

Nothing happens at the moment you type. A key press changes what the box is holding and stops there. No code of yours runs, and no variable moves. The box keeps the characters the way a piece of paper keeps what was written on it.

The value only travels when something asks for it. ask() takes a copy of what is in the box at that instant and hands the copy over. Type something else afterwards and the variable does not notice, for the same reason b did not notice in Step 3: it was given a copy, not a link.

Always text, which matters more than it sounds. Type 42 into a box and you get the two characters "42", not the number. Adding 1 to that gives you "421", because with text, plus means "stick together". The second lab in this step is that bug, on purpose.

Only questions with a yes or no answer. age >= 18 is one: it works out to either true or false, nothing else. > is greater than, >= is greater than or equal to, === is "exactly the same as", !== is "not the same as". Two questions can be joined into one with ||, two vertical bars, which means "or". The whole thing is true if either side is true, and the second side is not even looked at once the first one has said yes.

True and false are real values, as real as 7 or "hello", and you can put one in a box: let allowed = age >= 18 stores true or false. That turns out to be one of the more useful things in programming. It is why the comparison and the decision are two separate ideas rather than one.

Think of a list of rules, checked from the top, where the first one that matches wins and the rest are never looked at. That is exactly what a chain of else if is.

Which is why order matters enormously. If you check "over 10" before "over 100", then 500 matches the first rule and stops, and your "over 100" branch can never run at all. Put the narrowest rule first. This is a real bug that is hard to spot, because every individual line looks correct.

for (let i = 0; i < 10; i++) reads as three separate instructions separated by semicolons. Start with i at 0. Keep going while i is under 10. After each pass, add one to i. That last part is what i++ means.

i is short for index, and counting from 0 rather than 1 is a convention you will meet everywhere in Step 7. With i < 10 and a start of 0, the body runs for 0 through 9: ten times, which is what was wanted, and never with i equal to 10.

The dot means "reach inside this thing and use the part called that". drawn holds text, and every piece of text knows its own length, so drawn.length is the number of characters in it. If drawn holds "***" then drawn.length is 3. Read it left to right, as "the length of drawn".

The same dot turns up everywhere from here on and always means the same thing: quests.length in Step 7 is how many quests there are, and quest.title in Step 9 is the title of one quest. It is not doing anything clever. It is the difference between naming a box and naming one particular thing inside it.

Positions count from zero, so the first item is quests[0] and the second is quests[1]. This trips up everyone at first and there is a real reason for it: the position is a distance from the start, not an ordinal. The first item is zero steps along.

The consequence you will actually use: a list of 5 items has positions 0 to 4, so the last item is always at length - 1. Asking for quests[5] in a five-item list is not an error, which is worse than if it were. You get undefined, and the trouble surfaces later, somewhere else.

Think of a row of five houses, numbered from 0. The number of houses is 5. The number on the last house is 4. Both numbers are useful and they are never the same number.

So list.length is how many, and list[list.length - 1] is the last one. If you ever write list[list.length] you get nothing back, because you have walked one house past the end of the street.

A function can take material in and hand a result back. The names in the brackets when you write it are parameters: empty slots. The values you put in when you call it are arguments, and they fill those slots for that one run.

return is how a result comes back, and it also ends the function on the spot. A function with no return still does its work and hands back undefined. That is the right choice when the point is the doing, like drawing on screen and the wrong choice when the point is the answer. A bare return with nothing after it is allowed too: it hands back nothing and simply stops there, which is how a function leaves early when there is no work to do.

A list is things in an order, reached by number, where the order is the meaning: first, second, third. An object is things with names, reached by name, where the order does not matter at all.

Use a list when you have many of the same kind of thing and might need to walk through them. Use an object when you have one thing with several different aspects. QuestLog uses both together, and so does almost every real app: a list of objects.

It is an if and an else squeezed into one value. Read the question mark as "then" and the colon as "otherwise": if q.done is true the whole thing is "[x]", and if it is false the whole thing is "[ ]". It answers with a value instead of doing something, which is why it can sit in the middle of a line that is joining text together.

Written the long way it is four lines: let mark ="[ ]", then if (q.done) { mark ="[x]" }, then use mark. Both are correct and every checker in this course accepts either. The short form is worth being able to read even if you never write one, because other people's code is full of them.

quest.title and quest["title"] do the same thing. The dot is shorter and is what you will use nearly always.

The brackets earn their place when the name is in a variable: if field holds "title", then quest[field] reaches the title, while quest.field goes looking for something literally called field and finds nothing. That distinction matters the moment you write code that works on a field chosen at run time.

There is a real difference between award and award(). The first is the function itself, as a value you can hand to someone. The second is an instruction to run it right now.

So onClick(award) means "here is a function, keep it for later" and onClick(award()) runs it immediately and hands over whatever it returned, which is usually nothing. The button then does nothing forever. The brackets are the entire difference, and this catches everyone at least once.

Screen contents are just structure, from Step 1, and it stays exactly as it was put there. Change a variable and nothing on screen moves, because nothing is watching. The words on screen are a photograph of the data taken at the moment you drew it.

So a wrong screen has two possible causes, and telling them apart is most of debugging: either the data is wrong, or the data is right and nobody redrew. Printing the data is how you find out which, and it is why the lab below shows you both at once.

JSON.stringify(quests) takes your list of objects and produces one long line of text describing it exactly. JSON.parse(text) reads that text and builds the list again. Text goes in the cupboard; the pair of them get you there and back. JSON is just the name of that way of writing data down as text, and it is short for JavaScript Object Notation.

What comes back is a rebuilt copy, not the original. That matters the first time you save, reload, and find your changes going into a list nobody is looking at any more. The lab below lets you cause that.

null means "deliberately nothing". load() hands back null when the cupboard has never had anything put in it, which is what happens the very first time anybody opens your app. So if (quests === null) reads as "if nothing was saved", and the line after it starts you off with an empty list instead of crashing on a value that is not a list.

undefined, from Step 7, is the other kind of nothing: nobody ever set this, the way asking a four-item list for position 4 gives you undefined. A rough rule that will serve you for years: undefined is nothing by accident, null is nothing on purpose. Both are ordinary values, and both can be compared with ===.

Find the data first. One variable holds everything the app knows, and everything else exists to change it or show it. Then find the drawing function, which is the only thing that touches the screen. Then the handlers, one per thing a person can do.

Read in that order and any app makes sense, including ones far larger than this. Read top to bottom instead and it looks like a wall.

A long calculation keeps the main thread busy. Click handlers cannot run and the browser cannot paint intermediate DOM changes, so the page appears frozen even though the loop is still executing.

Break large work into chunks, move suitable computation to a Web Worker, or use a server. Do not add a timer merely to hide a calculation that still blocks for the same total time.

The HTML file is input. The browser parses it into DOM objects, and JavaScript can add, remove or change those objects. Saving the original file does not automatically save later DOM changes.

Browser developer tools show the current DOM, the console, network requests and storage. They are the first place to inspect when the screen differs from the data you expected.

It means an HTTP response arrived. A server can respond with 404 for a missing resource, 401 when no valid identity was supplied, or 500 when it failed internally. Check the status before trusting the response body.

A network failure, timeout and server rejection need different messages. Preserve enough information for a retry, but do not keep an endless spinner on screen.

Reading can usually be retried. Repeating a write may create two orders, payments or quests unless the operation is idempotent. An idempotency key lets the server recognise a repeated submission and return the first result.

Wait longer between repeated attempts and add a little random variation when many clients may retry at once. The reliability course develops backoff, timeouts and retry budgets in detail.

Every browser receives that file and can read it. A secret sent to a client is no longer secret. Keep database credentials and private service keys on a server, then expose only the operations clients are permitted to request.

Public identifiers, such as an API base URL, are not secrets. Classify each configuration value instead of hiding every setting or publishing every credential.

Applications change their stored shape over time. A migration is a numbered, reviewed change that adds or transforms schema in a repeatable way. Production data may be older than the current program.

Plan how old and new application versions overlap during deployment. The Inside a Database course follows indexes, transactions, logs and recovery below the API layer.

Do not store the password or a fast ordinary hash. Use a password-hashing function designed to be slow and memory costly, with a fresh salt for each account. At login, hash the candidate using the stored parameters and compare the result.

Multi-factor authentication reduces the damage from a stolen password. Account recovery deserves the same review as login because an easy recovery path can bypass stronger sign-in checks.

No. Hiding controls can make the interface clearer, but the request can still be sent directly. The server must decide using the authenticated identity, requested action and resource ownership or role.

Deny by default. Grant the smallest permission needed, record sensitive changes, and make expired or revoked sessions stop working.

HTTPS encrypts traffic in transit and authenticates the server name. It does not repair an XSS bug, stop an authorized server from collecting too much data, or make a stolen session harmless.

Cookies can be restricted with Secure, HttpOnly and SameSite attributes. A content security policy can limit which scripts and other resources a page may load. These are layers, not substitutes for safe code.

Collect the least personal data needed for the feature and keep it only as long as required. Access controls, deletion rules and backups must agree. Do not put passwords, session tokens or private quest text into ordinary logs.

Threat modelling asks what is valuable, who might misuse it, where trust changes, and how the design prevents or detects that misuse. Revisit the model when a new data flow is added.

An address has a machine name and a path to a file on it. The browser finds the machine, asks it for that file, and the machine sends the file back. That is the whole conversation. It is the same conversation for a photograph or a font.

Then the browser reads what came back and finds it mentions other files: a stylesheet, some JavaScript. So it asks for those too, one request each. Your app arrives as a handful of separate files and is assembled where it will be used, not where it was written.

A coding model can draft a function, explain an error or suggest a test. Treat the result as a patch from someone who has not seen the whole program: state the requested behavior, inspect the changed lines, run executable tests, and reject unrelated changes.

The model should receive only the files and permissions needed for the task. Generated code is not evidence that the program works; a passing check against the specification is. The Software Construction review lesson turns those rules into an interactive patch gate.

Let text wrap, let flexible columns stack, and keep controls large enough to operate. Test narrow and wide viewports, enlarged text, long translations, zoom and both pointer and keyboard input.

A media query changes rules when space or user preferences change. Respect reduced-motion and colour scheme preferences, but do not remove information when an animation is disabled.

Keep interface text outside business logic and mark the document language. Use locale-aware formatting for dates, numbers and plural forms. Do not join translated sentence fragments in a fixed English order.

Right-to-left scripts can change layout direction. Names, addresses and calendars also vary. Store the underlying value separately from its formatted display.

Git records snapshots and the parent relationship between them. A focused commit states one reason for change, includes its tests and can be reviewed or reverted without discarding unrelated work.

Branches let changes develop separately. A merge combines histories and may need a person to resolve places where both sides edited the same lines. Commit before a risky experiment.

Start from the requested behavior and likely failure modes, not from the patch's own explanation. Inspect every changed line, run the existing suite, add a regression test and check permissions, data handling, dependencies and unrelated edits.

A model can propose tests, but a test that repeats the same mistaken assumption proves little. Include boundary cases and, when possible, compare against an independent reference or property.

Store each pending operation locally with a unique ID, creation time and sync state. When connectivity returns, submit it idempotently. Mark it complete only after the server confirms the result.

If the remote record changed too, use an explicit conflict rule. Some fields can merge; others need the person to choose. “Last writer wins” is simple but can silently discard work.

A cache key that omits the signed-in user or language can return one person's data to another. Sensitive responses often need private or no-store rules. Shared caches must vary on every request property that changes the response.

Purging every cache after every change is safe but loses the performance benefit. Version immutable files and give changing documents deliberate validation rules.

Stop the rollout, limit further damage and restore a known working version when that is safe. A rollback may not reverse data changes, so migrations need forward and recovery plans.

After service returns, write a timeline based on evidence, identify contributing system conditions and add changes that improve prevention, detection or recovery. Do not stop at the last person who touched it.

A rate limit protects finite capacity and can slow abuse. It should define a scope, time window and useful response. A circuit breaker temporarily stops calls to a repeatedly failing dependency so work does not pile up behind it.

Retries consume capacity too. Limit attempts, use deadlines and make writes idempotent. Continue with Reliable Systems and Fault Tolerance for deeper failure models.

Use a coding model for bounded work: explain unfamiliar code, draft tests, propose a small patch, compare alternatives or search a codebase. Give it the relevant contract and minimum access needed. Keep generated changes in a reviewable diff.

Run the program and independent checks. Review security boundaries, dependencies, data migration and accessibility yourself. For uncertain behavior, make the model produce a test or source you can verify instead of accepting a confident explanation.

Software Construction develops specifications, invariants, test design, abstraction and review. Build a Language explains how source becomes tokens, syntax and machine instructions.

Use Inside a Database for storage, Performance Engineering for measurement, and Memory Exploits for low-level security boundaries.