JavaScript is not going anywhere. That is not a reluctant concession; it is just true. The browser runs it, Node runs it, the edge runs it, and the people who keep predicting its replacement have been wrong for 20 years and counting. If you're building for the web, you are building in JavaScript, one way or another.

The question is whether you want the version with guardrails.

The State of JavaScript 2025 survey put 40% of respondents as writing exclusively in TypeScript, and noted that figure keeps increasing and may soon represent the majority. Daniel Roe, the Nuxt core team lead, put it plainly: "TypeScript has won. Not as a bundler, but as a language." The notable part is that the same survey lists lack of static typing as the top pain point among JavaScript developers. Meaning the 60% who have not made the switch are still paying for it.

I spent a lot of years on the version without them. I was decent at it. I had a good mental model of the type coercions that would bite you, the undefined that showed up where you weren't expecting it, the function that returned a string in three cases and null in one case that nobody remembered to document. You get fast at this. You learn to read the patterns.

You also spend real hours, across real weeks, tracking down bugs that a compiler would have caught before you ran the code.

That time is not recoverable.

The Setup Argument Doesn't Hold Anymore

The most common reason people stuck with JavaScript was friction. TypeScript required a config, a build step, some decisions about strictness settings, and a round of "why is this complaining about something that obviously works." For solo projects or quick experiments, that overhead felt like a tax on momentum.

That argument is dead.

An LLM will scaffold a TypeScript project for you in the same number of prompts it takes to scaffold a JavaScript one. npx create-next-app, pnpm create vite, bunx --bun create-bun. They all default to TypeScript now. The config decisions have been made by the template and you can change them later if you have a reason to. The "I'll start in JavaScript and add types later" path is slower than just starting typed, because adding types to existing JavaScript means going back through code you already wrote.

There is no longer a meaningful difference in how fast you get to a working first file.

What You're Actually Trading

When you choose JavaScript over TypeScript for a real project, you are not trading complexity for simplicity. You are trading compile-time errors for runtime errors.

Runtime errors in production are more expensive than compile-time errors on your machine. This is not a complicated calculation. It's just that runtime errors feel optional until they happen.

I've debugged more "cannot read properties of undefined" errors than I want to count. In JavaScript, that message arrives at runtime, usually on the path you didn't test, usually after someone else's code updated the shape of the object you were depending on. In TypeScript, that category of error gets caught when you build. The compiler says: this field may not exist, handle that.

You handle it, or you find out you were wrong about the shape, or you add a type assertion and document why. Any of those outcomes is better than finding out in production.

The same goes for refactoring. Rename a function in JavaScript and you grep for it, hope you got everything, and find out at runtime that you missed one. Rename a function in TypeScript and the compiler tells you immediately what broke. This difference compounds over the life of a codebase.

Library Support Is Not the Problem It Was

There used to be a real argument that TypeScript was a second-class citizen in the JavaScript ecosystem. You'd reach for a library and find no types, or types that were wrong, or a @types/ package that lagged a major version behind. That was a legitimate frustration.

Most libraries now ship their own types. The ones that don't have accurate community types in DefinitelyTyped. The gap has closed to the point where it's unusual to reach for something and find no types at all. When it happens, you write a quick declaration file and move on. It's not a reason to avoid TypeScript.

The Frontend Case

If you're building a non-trivial frontend application, not a landing page or a form with three fields, but an actual application with state, API contracts, user roles, and components that talk to each other, TypeScript pays for itself early and keeps paying.

Modern frontend work is involved. The React component tree that makes sense on day one is the one that needs untangling on day 90, when two developers have added props and the original intent of a component is lost. Types don't fix bad design, but they do make the structure explicit. When a component breaks, you know what it was supposed to receive. When a prop name changes, you know everywhere it's used. When an API response changes shape, you find out at the type boundary instead of three components deep.

Interfaces cost you nothing to write and save you real time when something goes wrong. In a codebase maintained by more than one person, or by yourself six months from now, that's not a nice-to-have.

What I'd Tell Someone Starting Now

Use TypeScript. Not because it makes you a better developer, not because it's the Right Way. Because it catches a class of errors before they cost you anything, library support is comprehensive, and the setup friction that used to be a real objection is no longer real.

JavaScript is the language of the web. TypeScript is JavaScript with a compiler that works for you instead of against you. The lingua franca isn't going away; it's just getting a type checker.

Start typed. If you have a specific reason not to, you'll know what it is.