Old-School Front-End

First, meet the two people who will keep us company. Their names are a little joke in Japanese: Furui contains the character for "old", Arai the one for "new".

Vibe coding is a term Andrej Karpathy, one of OpenAI's founding members, coined in February 2025: you ask an AI in plain language, accept the code it writes without reading it closely, and carry on by feel. It caught on fast enough for Collins Dictionary to make it its 2025 Word of the Year. This blog covered it in the Dev Guide post Vibe Coding Field Notes. "Old-school" in this series means the exact opposite.

Asking an AI is faster, no question. We write by hand anyway, for three reasons.

• A person is still responsible for AI-written code — an expense app handles money. A total that is one yen off, or a missing input check, has to be found by someone reading the code. Code you cannot read is code you cannot check or fix
• The foundations do not change — whether an AI wrote it or it was built with React or Vue, what reaches the browser is HTML, CSS and JavaScript. Know those, and you can see inside whatever you are handed
• The old-school tools are still at work — W3Techs counted jQuery on about 64.5% of the websites it surveys in October 2026, and Bootstrap at about 75% of CSS-framework use. Company in-house systems have even more of them

An expense claim is how staff get back money they paid on the company's behalf (train fares, hotels on business trips and so on): they claim it, a manager approves it, and accounts pays it back. Here are the people involved and how a claim moves along.

Roughly, these are the features we will build.

There are rules to enforce, too. As on the expense page tested in the Dev Guide post Playwright in Practice: a receipt is required when the total reaches 30,000 yen, future dates are not allowed, dollar amounts are converted to yen, and so on. Part 9 covers how the screen enforces them.

1. Order (request) — the browser asks the server at the URL for the page
2. Delivery (response) — the server sends HTML. The browser then fetches the CSS and JavaScript files the HTML mentions
3. Reading — the HTML becomes a tree of page parts (the DOM), the CSS becomes a list of style rules (the CSSOM), and together they make a tree of only what will be shown (the render tree)
4. Arranging (layout) — positions and sizes are worked out for the width of the screen
5. Painting — text and colour are drawn into the screen's pixels

The key player is the DOM. When JavaScript changes a page it does not edit the HTML file; it rewrites the DOM inside the browser. Each rewrite reruns steps 4 and 5, so careless rewriting makes a page sluggish. We will meet this again in part 8.

The three front-end languages are easiest to picture as a body.

Seeing is believing. Here is the same claim form with the three added one at a time.

With HTML alone (1), the inputs and button already work: you can type and you can click. It just looks plain, and the total stays at 0. Adding CSS (2) makes it look like a business app, but it still does no maths. Calculating, and reacting when you click, is JavaScript's job. Here is what each step added (excerpts).

<!-- (1) HTML: what is there -->
<p>Total: <output id="total">0</output> JPY</p>
<button type="button" id="send">Submit</button>

/* (2) CSS: how it looks */
button { background: #c0392b; color: #fff; border-radius: 8px; }

// (3) JavaScript: how it moves
document.querySelector('#send').addEventListener('click', () => {
  document.querySelector('#toast').hidden = false;
});

No need to understand it yet. HTML comes in parts 2 and 3, CSS in parts 4 to 6, and JavaScript in parts 7 to 10, one step at a time.

A series that calls itself old-school owes you a few old stories.

• 1991 — Tim Berners-Lee at CERN opens the web to the public over the internet. The first web server was info.cern.ch
• 1994–96 — Håkon Wium Lie proposes CSS (October 1994). CSS1 becomes a W3C Recommendation in December 1996, fixing the idea that looks are written separately from HTML
• 1995 — Brendan Eich at Netscape builds the first JavaScript prototype in just ten days in May; it is announced in December
• 2006 — John Resig announces jQuery. It smoothed over the wildly different ways each browser had to be coded for, and spread fast
• 2011 — Mark Otto and Jacob Thornton at Twitter release Bootstrap
• 2021 — Bootstrap 5 no longer needs jQuery
• 2026 — jQuery 4.0 arrives in January, its first major version in nearly ten years (dropping Internet Explorer 10 and older). In October the first Bootstrap 6 alpha is published

We plan to use the stable versions at the time of writing: Bootstrap 5.3 and jQuery 4.0.

Just as you draw a floor plan before building a house, you draw a plan before building screens. First, the list of screens and how you move between them. The small print says which part mainly builds each one.

Next, the most important one, the claim form, in a little more detail. A drawing like this, without colour or decoration, showing only what goes where, is called a wireframe.

A plan surfaces questions before you build. What if a claim has more than ten line items? Are receipts only images, or PDFs too? Will anyone claim from a phone? Asking these up front saves rework later.

You need just three tools, all free.

One more essential tool comes built into the browser: the developer tools (DevTools). Think of them as an X-ray of the page. We will use them in almost every part.

Files go into folders by role, like this (this time we only make index.html).

With the tools ready, let's make the first page. Five steps.

1. Create a folder called keihi ("expenses" in Japanese) and open it in VS Code with Open Folder
2. Create index.html, type in the code below and save (in an empty file, type ! and press Tab for an instant template)
3. Install the Live Preview extension and open the preview with the button at the top right of the editor (or from the right-click menu)
4. Change some text and save, and check that the preview follows along
5. Open it in the browser, press F12 (Cmd + Option + I on a Mac) to open DevTools, and find the h1 in the Elements tab

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Expense System</title>
</head>
<body>
  <h1>Expense System</h1>
  <p>Under construction.</p>
  <p>Building work starts in part 2.</p>
</body>
</html>

Now let's break it on purpose. Delete </h1>, the heading's closing tag, and save…

Look in the Elements tab of DevTools and you will see both paragraphs sitting inside the h1. "When something looks wrong, check the shape of the tree in Elements first." That is the first debugging step, and we will use it again and again.

Finally, the road ahead. We are taking the stopping train, one station at a time.

The first half (parts 2 to 10) takes the three languages one at a time; the second half (parts 11 to 15) combines them into the features a business app needs. jQuery waits until part 14 because once you have written things in plain JavaScript yourself, you can see exactly what jQuery saves you.