JavaScript

The early web was a stack of documents you could only read. HTML said what was on the page and CSS said how it should look, and that was the whole toolkit. Both languages describe a page at rest. Neither of them can say what should happen after someone clicks something.

So even the smallest judgment had to make a round trip to the server. Type a six-character password into a signup form, press submit, and the value traveled to the server, which sent back an entire new page carrying one line: your password is too short. The screen flashed white on the way, and the name and email you had already typed were usually gone. Counting characters cost three seconds of network time, and the user started over.

JavaScript exists to remove that round trip. It sits next to the languages that describe the page and handles the part that reacts, which means some decisions now happen on the user's own machine instead of a server two hundred milliseconds away. A browser company wrote the first version in about ten days in 1995, and a few of the odd corners in the language today trace back to that deadline.

JavaScript does three jobs, and all three happen after the page has loaded.

1. Changing the page. The browser turns the document it loaded into a tree of objects called the Document Object Model (DOM), and JavaScript edits that tree directly. Inserting a new comment at the top of a list, or revealing an error message that was sitting there hidden, are both DOM edits.
2. Reacting to what the user does. You register code ahead of time against events like clicks, keystrokes and scrolling. Checking whether a password has passed eight characters now finishes while the user is still typing.
3. Talking to the server. Instead of fetching a whole new page, the code calls an application programming interface (API) on its own. An API is an agreed channel two programs use to exchange data. Infinite scroll works this way: hit the bottom of a list, request the next twenty rows, append them.

Having all three in one language is why JavaScript became the only practical choice inside a browser. For most of the web's history it was the only language a browser would read and run, and nothing has to be installed — opening the page is enough to download the code and execute it.

Where it runs has widened since. Once a runtime appeared that executes JavaScript outside the browser, server code could be written in the same language. Tools grew on top of it too: components as the reusable unit a large screen gets sliced into, and a bundler to pack those slices back into files a browser can fetch efficiently.

Nothing replaces JavaScript outright inside a browser. When engineers say alternative, they usually mean one of three things.

1. Use less of it. A screen with no real interaction needs only HTML and CSS. Plenty of things that used to require code — a menu that expands and collapses, a tab switcher — are now plain CSS. Less JavaScript means fewer bytes to download and parse, which shows up directly in how fast the first screen appears.
2. Write in a language that compiles to it. TypeScript is the common one. It adds syntax for declaring what type each value holds, and because browsers can't read that syntax, it gets converted to JavaScript before it ships. It's a layer on top, not a replacement underneath.
3. Hand the heavy computation to something else. WebAssembly is a second format browsers can execute, used for work like video editing or 3D rendering where the math is expensive and another language does it better. It still has to go through JavaScript to touch the page, so it never takes over the whole job, and most teams never reach for it at all.

In practice the decision is usually made inside option two. A two-person team skips type annotations and starts in plain JavaScript because writing them costs time it doesn't have. Once there are more screens and more people editing each other's code, the team moves to TypeScript. Pagedeck ran on plain JavaScript for its first six months and switched after the engineering team reached four people and the same function kept receiving differently shaped values, breaking the screen that used it.

"Do we actually need JavaScript here? Looks like CSS could handle the expand and collapse."

The same behavior is available without code, so don't attach any.

"The first load pulls more than 400KB of JavaScript. Let's strip out what nobody runs."

The diagnosis is the volume of code being downloaded, not any particular feature.

"I'm fine with moving to TypeScript, but let's leave the existing files alone and start with new ones."

The two languages will coexist for a while rather than switching over in one pass.

Most changes to Pagedeck's document editor happen in this language. When Noa asks for a spinner on the save button while a save is in flight, Theo hooks code onto two moments — the request going out and the response coming back — and swaps what the button looks like. Nothing new is fetched for the screen; one button on the page already open gets edited, so there is no flash.

The same language shows up on the other side of the ledger when something feels slow. After a report that the first screen takes too long, the first thing Theo measures is how much JavaScript the browser downloads up front. If the code for a settings screen most people never open is riding along in that first download, he splits it out so it arrives only when someone asks for it.

The most common assumption is that JavaScript is a relative of Java. The first four letters invite it, and the name really was borrowed from Java's popularity at the time. They are separate languages with different syntax, different design and different origins. Carrying Java habits across leads to a wall at the points where values behave differently than expected, and the time goes into hunting for a mistake that is actually a difference between two languages.

The other frequent mistake is thinking it only runs in a browser. Every beginner tutorial starts by manipulating a page, so the idea settles in early. In fact servers, command-line tools and deployment scripts are all written in it. Someone who believes otherwise concludes that moving toward backend work requires learning a new language first, and scopes what they can already build far too narrowly.