JavaScript Runs the World—Maybe Even Literally

In defense of a much-mocked programming language.
Two Java script brackets with a globe shooting through.
ILLUSTRATION: SAMUEL TOMSON

Lex Fridman has done many long interviews on his popular podcast. Even so, the episode with the legendary programmer John Carmack has an unhinged director’s-cut feel to it. Over five hours, Carmack dishes on everything from vector operations to Doom. But it’s something Fridman says, offhand, that really justifies the extended run time: “I think that if we’re living in a simulation, it’s written in JavaScript.”

To review: JavaScript is what makes static web pages “dynamic.” Without it, the internet would resemble nothing so much as an after-hours arcade, lifeless and dark. These days, the language is used in both front- and backend development for a whole host of mobile platforms and apps, including Slack and Discord. And the main thing to understand about it, in the context of Fridman’s nerdy koan, is this: For any self-respecting programmer, admitting to actually liking JavaScript is something of a faux pas—much like an art-house filmmaker confessing to Marvel fandom.

I suppose this has something to do with the fact that JavaScript was created in less time than it takes to home-brew a jar of kombucha: 10 days. In 1995, Netscape hired a programmer named Brendan Eich to create a language to embed in its browser, Netscape Navigator. Originally called LiveScript, the language was renamed JavaScript to piggyback on the hype around an unrelated language called Java, which had been introduced earlier that year. (Asked the difference between Java and JavaScript, a programmer is likely to joke: “Java is to JavaScript what car is to carpet.”) To this day, few people consider JavaScript a particularly well-designed language, least of all Eich. “I perpetrated JavaScript in 1995,” he once said, “and I’ve been making up for it ever since.”

What was his crime, exactly? You can easily find scads of blog posts, memes, and Reddit threads sandbagging JavaScript, but my favorite is a four-minute talk by software engineer Gary Bernhardt titled “Wat.” Imagine, for starters, showing a group of non-English speakers the present and past forms of verbs like boil (boil/boiled) and chew (chew/chewed). Then, when you ask them for the conjugation of eat, who could blame them for answering eat/eated? Similarly, the “Wat” talk is a blooper reel of JavaScript’s quirks and unpredictable behaviors. Let’s say you want to sort a list of numbers: [50, 100, 1, 10, 9, 5]. Calling the built-in sort function in any sane language returns the list in numerically ascending order: [1, 5, 9, 10, 50, 100]. Doing so in JavaScript returns [1, 10, 100, 5, 50, 9], where 10 and 100 are considered larger than 5. Why? Because JavaScript interprets each number as a string type and does lexical sorting, not numerical sorting. Total insanity.

When Fridman says JavaScript runs the world, in other words, what he means is that our world is, like the underlying source code, massively screwed up and incomprehensible. It’s the equivalent of pronouncing, with a sigh, that considering the sorry state of the planet, the Universal Declaration of Human Rights must have been written in Comic Sans.

At this point, I should confess that while JavaScript is not my favorite language, I like it. Adore it, in fact. So I can’t help but feel a flare of disapproval whenever a certain fraternity of programmers polemicizes against it. Often they focus on flaws that were dealt with years ago. To dwell on JavaScript’s original shortcomings is to overlook the fact that any piece of software—and every programming language is, in essence, a suite of software—is amenable to revision and improvement.

One of the principal criticisms of JavaScript is that it’s slow. This holds some truth in a general sense, but saying one language is “slower” than another is, technically speaking, an ill-formed objection. The performance of a language depends not only on the language itself but also on the caliber of its run-time environment—the setting in which the code is executed—and its compiler, which translates source code into a machine-readable format. Put differently, uncompiled code is akin to an uncast magic spell. Much as the potency of a spell depends on the caster, languages deemed “faster” but executed with crappy compilers could perform not much better than “slow” languages.

What’s more, JavaScript was, in a sense, bailed out of its terribleness by colossal advancements in software engineering and industry-wide efforts. Carmack acknowledges this in the same podcast: “The systems that make JavaScript run as fast as it does right now are kind of miracles of modern engineering in many ways.” A prime example is the Google Chrome team’s V8 JavaScript engine, which compiles JavaScript “just in time,” significantly boosting its performance.

If there were an equation to calculate the overall utility of a programming language, I’d bet the vibrancy of the language’s ecosystem would be an exponential variable that dominates the other linear terms. This is to say, no well-designed language is useful on its own without useful libraries. But when backed by a healthy community of developers, as is the case with JavaScript, even a modest language becomes supremely effective. (Python dominates scientific computing for similar reasons.) JavaScript is also an easy language, and by that I don’t imply any insult. Learnability is a killer feature.

JavaScript has undergone multiple iterations. The development of the language is steered by the rather unremarkably named Technical Committee 39 under a Geneva-based standards organization called Ecma International. (Imagine an international committee that could decide once and for all whether the past participle of get is got or gotten, and you have some sense of what TC39 does.) While some languages are governed by a conclave of experts, the process for JavaScript provides more visibility. Proposals and meeting notes are publicly available on GitHub. Meetings, once routinely held in the San Francisco Bay Area, have expanded to other places such as Bergen, Galicia, and Tokyo, as if to resist the notion that the tech industry can be metonymized by Silicon Valley. In some ways, JavaScript is the people’s programming language: egoless and all-embracing.

In a blog post titled “The Subjective Experience of Coding in Different Programming Languages,” the tech blogger Matt Webb explores the concept of “code synesthesia”: how coding in different languages can offer a “visceral, kinesthetic” experience. Many programmers often liken coding in Python, for instance, to writing in plain English, thanks to its friendly syntax. Likewise, reading old C code feels like engaging in the hermeneutics of ancient script, while Coq demands the exactitude of proving mathematical theorems. In this light, coding in JavaScript feels to me like an exercise in stenography—it affords a kind of buoyancy and effortlessness, allowing prototypes to be whipped up in an afternoon. While its namesake Java may be a reliable, muscular language, it lacks the charm and humor of its winsome sibling.

According to the annual Stack Overflow Developer Survey—as close to a global census of the industry as there is—2023 marked the 11th consecutive year that JavaScript has been the most commonly used language. Let’s be clear: I’m not trying to deny that vanilla JavaScript can be hacky. I am, however, trying to argue that there’s nothing fraudulent or even disagreeable about its ubiquity. In an industry that prides itself on the hacker ethos, calling JavaScript hacky may even be an honorific.

So an apology is in order, I think—and a congratulations. Look how far you’ve come, JavaScript, hopscotching across different eras of the internet, rising from a laughingstock to the lingua franca of the web. Well done, you ridiculous language. If I am being simulated by you, so be it.