The Birth and Death of JavaScript (2014): What Still Holds and What Doesn't

JavaScript runs in the browser with fewer privileges than any other runtime, and yet it ended up running servers, build tools, embedded databases, and CI pipelines. That wasn't a plan — it was an accumulation of patches on top of a decision made in 1995. Yes, 1995. And understanding why that happened — not just that it happened — changes how you design a stack today.

My thesis: Gary Bernhardt's "The Birth and Death of JavaScript" (2014) isn't nostalgia or failed prophecy. It's a diagnosis of architectural friction that's still active. But if you read it as a recipe, you're going to get burned. The value is in the problem it identifies, not in the solution it proposes.

The Real Problem the Talk Points At

Bernhardt describes an ironic arc: JavaScript was born as a toy language, survived because it was the only language that ran in the browser, and that monopoly position turned it — against all technical logic — into the most-executed language on the planet.

The central tension he identifies is this: the browser needs to run arbitrary code safely and fast, and those two things are in permanent conflict. His bet in 2014 was that ASM.js (and later WebAssembly, though he doesn't name it as such) would eventually replace JS as a compilation target, turning JavaScript into an assembly runtime that nobody writes by hand.

That didn't fully happen. WebAssembly exists, it's stable, and it has real use cases — Figma, Google Earth, video codecs — but it didn't replace JavaScript as an application language. What did happen is more interesting: JavaScript mutated. TypeScript, bundlers, transpilers, and alternative runtimes (Deno, Bun) are all attempts to fix the same frictions Bernhardt was pointing at, without abandoning the ecosystem.

What's worth extracting from the talk in 2025 isn't the prediction — it's the question underneath it: what part of my stack exists because it's the best technical solution, and what part exists because it was the only thing that ran in that context?

What's Worth Testing Today With That Framework

Bernhardt's framework — "the right language in the right place vs. the language that won by accident" — is directly applicable to current architecture decisions. Not as doctrine, but as a questioning checklist.

Take a typical stack like mine at juanchi.dev: Next.js, TypeScript, PostgreSQL, Railway. Some of those technical decisions survive Bernhardt's scrutiny. Others don't.

Architectural friction checklist (Bernhardt-style):

Concrete, reproducible example: TypeScript on the server (Node.js/Next.js API routes) holds up well against that checklist. The compilation overhead exists, but the benefit in type contracts between layers is measurable — you can see it in any codebase where Zod validates at runtime what TypeScript promises at compile time. I wrote about that in Zod on the server and client: the real friction isn't the transpiler, it's the gap between what the type says and what actually arrives over the network.

JavaScript on the server (Next.js App Router, for example) holds up with more caveats. The caching model is a non-obvious contract — I detailed it in Next.js App Router caching — and part of that complexity exists because the same runtime is trying to be client, server, and edge simultaneously. That's exactly the kind of tension Bernhardt was describing: a technology expanding into territories it was never originally designed for.

Where People Go Wrong Reading This Talk

The most common mistake is using "The Birth and Death of JavaScript" as an argument to avoid learning JavaScript deeply, or to justify jumping to WebAssembly before you have a real performance problem.

The hidden cost of that mistake:

The counterexample I care most about: Spring Boot, which comes from my history with Java, has its own inherited frictions — XML, verbosity, slow startup in serverless contexts. But that's not a reason to abandon Java. You use tools like GraalVM native image or you adjust the use case. Bernhardt's talk applies there too: Java in a giant JAR that starts in 8 seconds exists because it solves a real enterprise ecosystem problem, not because it's technically optimal for a serverless function.

The wrong recipe is: hear the critique and throw everything out. The right one is: understand what specific friction exists and whether it has a solution within the current stack or requires a layer change.

For auth decisions, that same logic applies: JWT, Paseto, and session tokens aren't chosen by fashion but by the specific friction of each context. Bernhardt would've applauded that decision tree.

Gotchas: Where the 2014 Analysis Has an Expiration Date

Three points where the talk ages badly and it's worth being explicit:

1. WebAssembly didn't replace JavaScript as an application language

Wasm is stable, has support in all modern browsers, and there are solid use cases. But the interoperability cost with the DOM is still high. Writing web applications directly in Wasm — without JS as glue code — is still a niche use case. Bernhardt assumed the performance weight would force the migration; in practice, JS engines (V8, SpiderMonkey) improved enough that the pressure wasn't critical for most cases.

2. The npm ecosystem as an inertia factor

In 2014, npm had tens of thousands of packages. Today it's over a million. That critical mass didn't exist in Bernhardt's analysis. The friction of migrating an ecosystem at that scale is a real technical argument, not just a political one. Deno tried with its own registry and had to go back to npm compatibility to gain adoption. Bun tried by prioritizing compatibility from day one.

3. TypeScript changed the equation

Bernhardt's critique of JavaScript implicitly includes the lack of types. TypeScript — which in 2014 was version 1.0, just launched — wasn't on his radar as a response. Today it's the mainstream answer to that specific friction. Not perfect — I documented the runtime type edge cases in the Zod post — but enough to change the analysis.

Talk validity checklist:

Decision Matrix: When to Use This Analysis and When to Ignore It

Not every technical decision needs Bernhardt's framework. Here's the matrix for when it applies and when it's a distraction:

For tools like the ones described in the MCP Model Context Protocol post, Bernhardt's analysis is relevant: you're deciding whether your tool's runtime is TypeScript/Node, Python, or something compiled. That decision has real portability costs. For a CRUD API with Prisma and PostgreSQL — like the one I describe in Prisma query logging — Bernhardt's analysis is noise: the bottleneck is almost never the JS runtime.

FAQ

Who is Gary Bernhardt and why does this talk keep circulating?

Gary Bernhardt is known primarily for "Wat" (2012), a short talk that exposed weird JavaScript and Ruby behaviors with humor. "The Birth and Death of JavaScript" (2014) is different: it's a multi-minute analysis of the language's history and possible evolution, presented in satirical talk format but with real technical arguments. It keeps circulating because the tension it describes — runtime monopoly vs. technical merit — was never resolved. It mutated.

Did WebAssembly end up killing JavaScript as the talk predicted?

No. Wasm has real and growing use cases, but it coexists with JavaScript; it doesn't replace it. The main reason is the interoperability friction with the DOM and the npm ecosystem. Compiling to Wasm adds toolchain complexity that only pays off when you have a measured performance bottleneck. For most web applications, V8 is fast enough.

Does it make sense to learn WebAssembly if I work with TypeScript/Next.js?

Depends on what you want to do. If you write standard web applications, no. If you work with image processing in the browser, codecs, physics simulations, or tools that were originally native binaries, then yes — it's worth understanding Wasm as an option. The criterion isn't "JS is going to die," it's "do I have a CPU bottleneck in the browser that JS can't resolve?"

Does Bernhardt's analysis apply to the backend too?

Partially. On the backend, the runtime choice is freer — there's no browser monopoly — so the tension he describes is smaller. Java, Go, Rust, Python, and Node.js compete on equal footing. There, Bernhardt's analysis becomes a different question: are you choosing Node because it's the best tool for the problem, or because your team already knows JS and you want to share code with the frontend? Both are valid reasons, but they're different reasons with different costs.

Why doesn't TypeScript solve all the problems Bernhardt identified?

TypeScript solves type friction at compile time. It doesn't solve type friction at runtime — what arrives over the network doesn't respect the TypeScript schema unless you validate it explicitly with something like Zod. It also doesn't solve the performance problems of the JS runtime, the complexity of the event loop, or the lack of real concurrency primitives. TypeScript is a significant improvement over untyped JavaScript, but it's an improvement within the same runtime — not a paradigm shift.

When does it actually make sense to evaluate a runtime change instead of sticking with JS/TS?

When you have measured evidence, not intuition. Concrete criteria: unacceptable p95 latency after optimizing the JS code, need for real parallelism (not event loop concurrency), integration with native libraries where the FFI overhead is a problem, or a team with deep expertise in another runtime that justifies the switching cost. Without those conditions, changing runtimes is premature optimization with ecosystem cost attached.

Where This Leaves Me as an Architect

Honest take: Bernhardt's talk is more useful to me as a questioning exercise than as a roadmap. The framework — "is this technology here on merit or because of monopoly?" — is a question worth asking for every layer of the stack. Not to throw everything out, but to know exactly what you're paying and why.

What I don't buy from the popular reading of the talk: that WebAssembly is the inevitable future and JS is a zombie waiting to be replaced. That ignores the weight of the ecosystem, the speed of modern engines, and the fact that TypeScript significantly changed the type equation.

What I do buy: there are inherited frictions in the JS/TS stack that aren't going away with the next framework. The Next.js App Router caching model, the gap between static types and runtime validation, the complexity of the event loop under mixed workloads — those are real frictions that Bernhardt would've recognized even if he didn't name them specifically.

My practical recommendation: read the talk once, run the questioning checklist against your current stack, measure before changing any runtime, and don't use a 2014 prediction to make a 2025 architecture decision without your own data. The friction Bernhardt identifies is real. The solution he proposes already has an expiration date.

The concrete next step: grab one layer of your stack where you feel friction and run it through the checklist above. Not to change it — just to know whether the friction comes from the problem or from the tool.