Ten Days in May: How the World's Most Used Language Was Born in a Week and a Half

In May 1995, a programmer named Brendan Eich was given one of the strangest briefs in the history of software. His employer, Netscape — the company behind the web browser that defined the early internet — wanted a small scripting language baked into the browser so that web pages could do things: validate a form, react to a click, make the page feel a little bit alive. The catch was the timeline. He had about ten days to design and build it before a looming deadline.

Ten days. Not ten days to polish an existing idea, but ten days to invent a programming language from scratch, write its first interpreter, and wedge it into a shipping browser. Most languages are the product of years of committee debate, academic papers, and careful iteration. This one was conjured in the time it takes to go on holiday. The result of that frantic week and a half is now, by most measures, the most widely used programming language on Earth — it runs in every web browser, on servers, in phone apps, on smart watches, and quite possibly in the device you're reading this on right now. And almost every one of its famous oddities can be traced straight back to the pressure of those ten days.

If you've ever wanted to poke at the language yourself and see its strange beauty first-hand, you can do it instantly in an online JavaScript compiler — no installation, no setup, just type and run. Many of the quirks in this article are more fun when you watch them happen with your own eyes.

The name was a marketing lie

Here's the first thing almost nobody knows: JavaScript has essentially nothing to do with Java. They are about as related as a car and a carpet — they share four letters and not much else. Java was a separate language, made by a different company (Sun Microsystems), and in 1995 it was the hottest thing in tech, drowning in hype.

Eich's language was originally called Mocha, then briefly LiveScript. But Netscape had struck a marketing partnership with Sun, and someone in a meeting made a fateful decision: rename the new language "JavaScript" to ride the wave of Java's popularity. It was, in plain terms, a branding move — borrowing the glamour of a famous name for an unrelated product. The decision stuck, and it has confused beginners ever since. To this day, working programmers wearily explain that "Java is to JavaScript as ham is to hamster." A snap marketing choice in 1995 created a naming headache that has lasted three decades.

Why the weird parts are weird

Spend any time with JavaScript and you'll bump into its infamous quirks — behaviours so strange they've inspired conference talks, comedy routines, and an entire genre of "wat?" internet humour. The temptation is to assume the language was badly made. The truth is more interesting: most of the quirks are the fossilised footprints of that ten-day sprint and the decisions that followed.

Take the most notorious one. In JavaScript, if you ask for the type of null — a value that means "nothing here" — the language confidently tells you it's an "object". This is plainly wrong; null is not an object. It's a genuine bug, and it dates back to the very first implementation, a consequence of how values were tagged in memory in that original rushed interpreter. By the time anyone noticed, fixing it would have broken existing web pages that had come to depend on the wrong answer — so the bug was kept, deliberately, forever. Run console.log(typeof null) in any browser today and you'll still get "object", a thirty-year-old mistake preserved like an insect in amber.

Then there's the arithmetic that seems to fail basic maths. Ask JavaScript what 0.1 + 0.2 equals and it will tell you 0.30000000000000004. This one isn't actually JavaScript's fault — it's how nearly all computers store decimal numbers, a standard called floating-point that can't represent 0.1 exactly any more than you can write one-third as a finite decimal. But JavaScript exposes it more openly than most languages, and so it became the canonical example of "computers are weird." Try it yourself and watch the stray digits appear.

Or consider NaN, which stands for "Not a Number" — the value you get from a nonsensical calculation. Bizarrely, NaN is not equal to itself: ask whether NaN === NaN and the answer is false. The reason is rooted in the same international floating-point standard, which decided that two undefined results shouldn't be considered the same thing. It's logical once you know the history, and baffling until you do.

The double-equals trap

Perhaps the most consequential quirk is JavaScript's habit of trying to be helpful when comparing things. The language has two ways to check if two values are equal: a strict one (===) that compares without fiddling, and a loose one (==) that will quietly convert types to make a match. That loose comparison leads to a hall of mirrors. An empty string can equal zero. The string "0" is loosely equal to false. There are chains of comparisons where A equals B and B equals C, but A does not equal C — breaking the most basic rule of equality you learned in school.

This wasn't malice; it was an attempt to make the language forgiving for non-programmers writing little snippets in web pages, back when that was the whole point. The lesson the community eventually drew — "always use ===" — is now one of the first things any JavaScript developer learns. But the friendly, dangerous == is still in the language, because of the unbreakable rule that governs everything: you cannot break the web.

"Don't break the web"

That rule deserves its own moment, because it explains why JavaScript has never simply cleaned up its mistakes the way other languages do. The web is the largest body of deployed software in human history. Billions of pages, many of them decades old, written by people long gone, sitting on servers nobody maintains. If a new version of JavaScript changed how an old feature behaved, some unknowable fraction of those pages would silently break, and there would be no one to fix them.

So the people who steward the language operate under a near-sacred principle of backward compatibility. New features are added; old behaviour is almost never removed, no matter how embarrassing. This is why typeof null is still "object", why == still does its strange dance, why the language accretes new layers instead of tearing out old ones. JavaScript is less like a building that gets renovated and more like a city that just keeps growing outward, every historical era still standing. It's a remarkable feat of discipline, and it's the reason a script written in 1997 will, astonishingly, still run today.

From toy to titan

For its first decade, JavaScript was widely dismissed as a toy — a language for making text scroll across status bars and popping up annoying alert boxes. Serious programmers looked down on it. Two things changed that.

The first was a technique that came to be nicknamed Ajax in the mid-2000s, which let web pages quietly fetch new data and update themselves without reloading. Suddenly a web page could feel like a real application — think of the first time an online map let you drag the view around smoothly instead of clicking and waiting for a full reload. JavaScript was the engine behind it, and the toy started to look like a power tool.

The second was a fierce, multi-year arms race between browser makers to run JavaScript faster. Engines were rebuilt to compile the language to fast machine code on the fly — "just-in-time" compilation, which is, incidentally, why calling it a "compiler" isn't entirely wrong even though you never see a compile step. JavaScript went from sluggish to startlingly quick. Then in 2009 it broke out of the browser entirely: a project called Node let JavaScript run on servers, and the language that was supposed to validate form fields started powering the back ends of major companies.

Along the way it got a proper rulebook. To stop rival browsers from inventing incompatible dialects, the language was handed to a standards body, and the official specification is called ECMAScript — a deliberately awkward name that Eich himself reportedly compared to a skin disease. That's why you'll see version names like "ES6" or "ES2015": those are editions of the standard, a formal description of a language that began as a ten-day hack.

The beauty in the chaos

It would be easy to read all this as a catalogue of mistakes, but that misses something. A language built in ten days, saddled with a misleading name, frozen into backward compatibility, and dismissed as a toy went on to become the connective tissue of the modern internet. It is the only programming language that runs natively in every web browser without anyone installing anything. It is, for millions of people, the first language they ever learn, precisely because the barrier to entry is so low: you don't need a compiler, a setup, or even a text file. You can write a line of it and watch it run in seconds.

That accessibility is the real legacy of those ten days in May. Eich wasn't building a cathedral; he was building something fast, forgiving, and available to everyone — a language you could experiment with right where you already were, inside the browser. Thirty years later, that's still the most delightful way to learn it. You don't have to take any of these quirks on faith. Open an online JS compiler, type console.log(typeof null) or console.log(0.1 + 0.2), press Run, and meet the ghosts of 1995 in person.

The language has its warts, and its creator has been refreshingly honest about them over the years. But there's a quiet kind of wonder in the fact that something assembled in a frantic week and a half — a language whose name was a marketing fib and whose bugs became permanent features — ended up being the thing that taught the world to code. Most software is forgotten in a decade. JavaScript got ten days at birth and has been running, more or less without pause, ever since.