Before the Code Runs

Let's start with the person who actually built this thing.

In 1995, Brendan Eich was working at Netscape, and he was given a strange deadline: build a scripting language for the browser, in about ten days. Not ten weeks — ten days. And the language he wrote in that window is still running, mostly unchanged, on billions of devices today.

It also didn't keep its first name. He called it Mocha at first, then it became LiveScript, and only later got renamed to JavaScript — mostly because Java was popular at the time, and the name change was a marketing decision. The two languages don't actually have much in common beyond that.

But naming trivia aside, here's the real question: why did a new language even need to exist?

console.log("Hello, World");

Running a line like this feels completely normal today. But go back to the early web, and it wasn't like this at all. HTML could describe a page. CSS could make it look decent. Neither one could make anything actually happen. You could put a button on a page, and clicking it would do nothing. The page just sat there.

That's the gap JavaScript was built to fill.

The Web Needed Behaviour

Think about a simple signup form. Before JavaScript, if you left the email field empty, there was no way to catch that in the browser. You'd have to submit the form, wait for the server to respond, and then reload the whole page just to see "you forgot your email."

JavaScript is what fixed that. HTML handled structure, CSS handled how things looked, and JavaScript handled what actually happened when you interacted with the page — right there in the browser, no reload needed.

button.addEventListener("click", () => {
  console.log("Button clicked");
});

Now the page could react to you immediately.

Structure, presentation, behaviour — HTML, CSS, JS. It's a simple way to split things up, and honestly, it still holds up today.

That explains what JavaScript added. It doesn't explain why it had to be JavaScript, specifically.

Why Not Just Use C++?

C++ already existed, and it was already fast and powerful. So why not just use it in the browser?

Here's the problem: C++ compiles down to machine code ahead of time, for one specific machine. That's great for performance, but it means the code only works on the exact setup it was built for.

The web didn't have that luxury. A page had to open the same way on a Mac, a Windows PC, or whatever someone happened to be using — without anyone recompiling anything for them.

So JavaScript went a different way. Instead of compiling ahead of time for one machine, it relies on the browser to provide the environment and an engine to read and run the code on the spot. You write the JavaScript, and the engine figures out how to actually run it on whatever machine it ends up on.

Why It Needed Guardrails

There's another problem C++ would have caused: trust.

If a website could run raw, native code with full access to your system, that's a real risk. It could read your files, run commands, or reach into your hardware — all without asking. Nobody wants to visit a page and later find out it deleted something while they weren't looking.

So the browser keeps JavaScript inside a controlled space. It can't just reach into your system on its own. Things like your camera, microphone, or location are locked behind a permission prompt, and everything else runs inside a boundary the page can't get past.

Why It Had to Be Small

One more thing worth remembering: the machines back then were tiny by today's standards. A typical computer in 1995 had a few megabytes of RAM, total. A single browser tab today can use more memory than that.

So nobody was going to install a separate app just to make one webpage interactive. JavaScript had to be small enough to load with the page itself, and simple enough that regular web developers — not just systems programmers — could actually use it.

C++ wasn't a bad language. It just wasn't built for this job.

What the Engine Is Actually Doing

In a language like C, if you forget to free memory, you get a leak. Free it twice, and the program can crash. JavaScript avoids all of that — the engine keeps track of what's still being used and cleans up what isn't, automatically, through something called garbage collection. You still need to understand how memory works; you just don't have to manage it by hand.

Modern engines do even more than that. They read your code, compile the parts that run a lot, and keep optimizing them while your program is actually running. That's what JIT (Just-In-Time) compilation means.

There's more depth to this than we need right now. For today, here's the one idea worth holding onto:

JavaScript doesn't run directly on the machine. The engine sits in the middle, and it's doing more work than it looks like.

One Language, a Few Different Engines

Here's something worth knowing: "JavaScript" and "ECMAScript" aren't quite the same thing.

ECMAScript is the actual specification — the rules the language has to follow. JavaScript is the language you actually write, built on top of that spec. And different browsers run it through different engines:

Same spec, three different engines underneath, each one turning your code into something the machine can actually run.

Before We Go Further

So, to sum it up: JavaScript isn't the browser, and it isn't machine code either.

The browser gives it a place to run. The engine reads the code and figures out what to do with it. The machine carries out the actual instructions underneath all of that.

And once your JavaScript reaches the engine, there's one more question worth asking.