How did JavaScript escape the browser?

The full story

The episode's narration, word for word. Numbers link to the sources below; timestamps play that moment.

The question 0:00

JavaScript was built to live inside web pages ¹. Yet today the same language answers requests on servers, runs desktop apps, and powers the tools programmers use to build websites ^2,3,4. So how did a language made for the browser get out? The answer is a program called Node.js, and a very old idea about waiting.

Berlin, 2009 0:24

Netscape had even tried running JavaScript on servers back in the nineteen-nineties ¹. But the one that stuck was shown off on the eighth of November 2009, in Berlin, at the first European JavaScript conference ^5,1. A programmer named Ryan Dahl walked through a project he called Node ⁵. It was small then: about ten thousand lines of code, from fourteen contributors ⁵.

An engine you could take home 0:51

Node was built on V8, the JavaScript engine from Google's Chrome browser ^5,1. An engine is the part that actually reads JavaScript and runs it ⁶. When Chrome launched in September 2008, Google released its code as open source, V8 included ⁷. Dahl took the engine out of the browser and bolted on what a browser never lets web pages do freely: read files, open network connections, and start other programs ^5,1.

What a server mostly does 1:21

But Dahl's real target was a problem with servers ⁵. A server is a program that answers requests from other computers: open a web page, and a server builds the reply, often after asking a database ⁵. Dahl put one line of that kind of code on a slide and asked what the software is doing while the database works ⁵. His answer: in many cases, just waiting ⁵.

How long is a wait? 1:47

He showed how long that wait is, counted in processor cycles, the ticks of the chip's clock ⁵. Fetching from the chip's own fastest memory took about three ticks ⁵. Reading from a disk took about forty-one million, and waiting on the network, two hundred and forty million ⁵. Stretch it so that the fastest step takes one second, and a disk read takes about five months, and a network reply about two and a half years ⁵. Those are Dahl's 2009 figures, and disks are faster now, but the point stands: a server spends most of its life waiting ⁵.

One waiter per table 2:25

The usual fix was threads ^5,2. A thread is a separate line of work that the operating system switches between, so a program can wait on many things at once ⁵. Dahl pointed to the popular Apache web server, which used one thread per connection ⁵. Picture a restaurant with one waiter for every table, each standing by the kitchen door while their order cooks. Every waiter costs memory, and switching between them costs time ⁵. Engineers had been wrestling with that limit for years: Dan Kegel called it the C10K problem, serving ten thousand clients at once ⁸. Dahl argued that one thread each just doesn't scale ⁵.

One waiter, many tables 3:07

Now picture one waiter for the whole room. They take an order, pin it up for the kitchen, and move straight on to the next table. When a dish is ready, a bell rings, and they carry it out. That's an event loop ^5,2. In code, the bell is a callback: a function you hand over, to be run later, when the result arrives ⁵. Dahl's design goal was that no function should sit and wait for a disk or a network ⁵. Ask, leave a callback, move on. Node does keep a few waiting versions, like the first one you're about to see ².

The same program, two ways 3:45

Here's what that looks like in real Node code, run for this episode. The first version reads a file and waits for it, so it prints the menu, then moves to the next table ⁹. The second asks for the same file and hands over a callback ⁹. So it says "next table" first, and prints the menu when the file arrives ⁹.

Why JavaScript? 4:08

So why JavaScript, of all languages? Dahl's slides made the case ⁵. Most programmers were taught to demand input and do nothing until they have it, and most existing libraries worked that way too ⁵. JavaScript grew up in the browser, where everything already happens through events: a click, a key press, a page finishing loading, each handled by a callback ⁵. As Dahl put it, the culture of JavaScript was already geared towards evented programming ⁵. It arrived on the server with no habit of waiting.

Who's in the kitchen? 4:42

Back in the restaurant, who actually does the waiting? Underneath Node is a library called libuv, originally written for Node itself ¹⁰. For network connections, it asks the operating system to keep watch and report which connections have something ready ¹⁰. Files are trickier, so libuv hands those to a small pool of helper threads, four by default ^10,11. So it's not really a one-person restaurant. Your JavaScript runs on one thread, but there are cooks in the kitchen ¹².

The waiter can't cook 5:16

And here's where the analogy breaks hardest. The waiter can take orders all night, but if your own code does heavy work, the waiter is cooking, and every table waits ¹². In this real example, a timer asks to run after ten milliseconds. Then the code keeps the thread busy for half a second, and the timer can't run until it's done ¹². Node's own guide warns that a slow callback stalls every client, and can even be abused to freeze a server for everyone ¹². For heavy computing, Node later added worker threads ¹³.

A web server in four lines 5:52

And it made servers short to write ². These four lines are a complete web server, and they run. Every time someone connects, the callback answers "Hello from Node" ². With nothing to do, Node simply sleeps ².

Packages: npm 6:10

The next piece arrived in January 2010: npm, a package manager written by Isaac Schlueter ^1,14. A package is a bundle of someone else's code, published so anyone can pull it into a project with one command ^15,14. Today npm calls itself the world's largest software registry, holding millions of packages ^15,14. Dahl later credited it with letting the whole ecosystem grow outside Node's core ¹⁶. In 2012, he handed the running of Node itself to Schlueter ¹.

Eleven lines 6:46

Packages depend on packages, which depend on more packages ¹⁷. In March 2016, after a dispute over a package name, developer Azer Koçulu removed two hundred and seventy-three of his packages from npm ¹⁷. One was left-pad, eleven lines that pad a string with spaces or zeros ¹⁸. Thousands of projects relied on it, often without knowing, and npm saw hundreds of failures a minute ^17,18. Today the language has that built in, as padStart ¹⁹. The lesson stuck: every package brings its own dependencies along.

Growing pains 7:27

Node grew up in public. In 2011, Microsoft helped bring it to Windows ¹. In 2014, unhappy with how the project was run, a group of contributors split off a copy called io.js ¹. In 2015 the two reunited under a new Node.js Foundation ¹. Since 2019, Node has been looked after by the OpenJS Foundation, a neutral home that also hosts other JavaScript projects ^1,3.

What Node runs today 7:59

So what is it used for? Web servers and the back ends of apps, which was its first job ². The tools that build and test websites, many of which run on Node ⁴. And desktop apps: Electron packs Chromium, the open-source core of Chrome, together with Node, and VS Code, Slack and Discord are built with it ³. In Stack Overflow's 2025 survey, 48.7 percent of people who answered said they'd done extensive work with Node.js in the past year, the most of any web technology listed ²⁰. That's survey takers, not every programmer.

The fair criticism 8:39

Some of Node's bad reputation is deserved. Callbacks inside callbacks get hard to read. Dahl himself had added promises, objects that stand for a result that hasn't arrived yet, then removed them in 2010, and later called that a mistake ¹⁶. JavaScript eventually got promises and the await keyword anyway, and Node followed ¹⁶. Heavy computation is still a poor fit for one busy thread ^12,13. And the registry has no vetting, so a package can be careless or even malicious ¹⁴.

The creator's second try 9:15

In 2018, Dahl gave a talk about his regrets in Node ^16,21. One line from his slides: your linter shouldn't get complete access to your computer and network ¹⁶. His answer was a new runtime, Deno, which reached version one in May 2020 ⁴. By default, a Deno script can't touch your files or the network unless you allow it ⁴. Run the same server in Deno, and it stops and asks for permission to use the network. Say no, and the server never starts; add a flag, and it runs. Since version two in 2024, Deno says it can run existing Node projects too ²².

And Bun 10:00

Then there's Bun, started by Jarred Sumner, which reached version one in September 2023 ²³. It aims to be a drop-in replacement for Node, with its own package manager and test tools built in ²³. Unlike Node and Deno, it uses the JavaScript engine from Apple's Safari ²⁴. Its speed claims are its own, so check them for your own work ²³. In December 2025, Bun was bought by Anthropic, the company that makes Claude, the AI that helps research and script this channel ^25,26. All three run JavaScript outside the browser, and none is the right answer for everyone.

Out of the box 10:42

So JavaScript escaped because three things lined up. A fast engine became free to take home ^7,6. An old idea, one waiter for many tables, needed a language with no habit of waiting ⁵. And npm let people share the pieces ^14,16. Notice one more thing: Deno was built to run TypeScript, a version of JavaScript with extra rules, straight away, and Node and Bun now can too ^4,23,27. Why would anyone add rules to JavaScript on purpose?

Sources

Every factual claim in the episode is tied to one of these. Spotted an error? Tell us.

1. Wikipedia, "Node.js" (accessed 7 October 2026) — en.wikipedia.org
2. Node.js, "About Node.js" — nodejs.org
3. Electron, project home page and showcase — electronjs.org
4. Deno blog, "Deno 1.0", 13 May 2020 — deno.com
5. Ryan Dahl, "node.js" (slides), JSConf EU, Berlin, 8 November 2009 — tinyclouds.org
6. V8 project, "What is V8?" — v8.dev
7. Chromium Blog, "Welcome to Chromium", 2 September 2008 — blog.chromium.org
8. Dan Kegel, "The C10K problem" — kegel.com
9. Node.js, "Overview of Blocking vs Non-Blocking" — nodejs.org
10. libuv documentation, "Design overview" — docs.libuv.org
11. libuv documentation, "Thread pool work scheduling" — docs.libuv.org
12. Node.js, "Don't Block the Event Loop (or the Worker Pool)" — nodejs.org
13. Node.js API documentation, "Worker threads" — nodejs.org
14. Wikipedia, "npm" (accessed 7 October 2026) — en.wikipedia.org
15. npm Docs, "About npm" — docs.npmjs.com
16. Ryan Dahl, "Design Mistakes in Node" (slides, the "10 Things I Regret About Node.js"… — tinyclouds.org
17. npm Blog (archive), "kik, left-pad, and npm", 23 March 2016 — blog.npmjs.org
18. The Register, "How one developer just broke Node, Babel and thousands of projects in… — theregister.com
19. MDN Web Docs, "String.prototype.padStart()" — developer.mozilla.org
20. Stack Overflow Developer Survey 2025, Technology — survey.stackoverflow.co
21. Wikipedia, "Deno (software)" (accessed 7 October 2026) — en.wikipedia.org
22. Deno blog, "Announcing Deno 2", 9 October 2024 — deno.com
23. Bun blog, "Bun 1.0", 8 September 2023 — bun.com
24. Wikipedia, "Bun (software)" (accessed 7 October 2026) — en.wikipedia.org
25. Bun blog, "Bun is joining Anthropic", 2 December 2025 — bun.com
26. The Register, "Zig creator calls Bun's Claude Rust rewrite 'unreviewed slop'", Joab… — theregister.com
27. Node.js API documentation, "Modules: TypeScript" (history: "v23.6.0, v22.18.0 Type… — nodejs.org

Researched and scripted with AI assistance, fact-checked claim by claim, with synthetic narration and diagrams drawn in code. How we make episodes.