TypeScript Adoption in 2026: The Argument Is Over

In 2015 I was writing ES5 and jQuery, and TypeScript felt like homework. Triple-slash references, a compiler that argued with me, and clients who wanted features by Friday. Types were a thing you did at a bank.

I was wrong, but so was most of the industry, and the interesting part is not that TypeScript won. It is what the win actually looks like now that the argument is over.

The numbers, briefly

The State of JavaScript 2025 survey, published in February 2026, puts it plainly: 40% of developers now write exclusively in TypeScript. That is up from 34% in 2024 and 28% in 2022. A steady climb, not a spike.

The number I find more telling is the other end of the scale. Only 6% now write plain JavaScript exclusively.

Six percent. That is not a competing camp, that is a rounding error with opinions. Meanwhile roughly two thirds of professional developers use TypeScript in some form, and it consistently posts satisfaction scores in the mid eighties among people who actually use it.

For context on how fast this moved: when I started ignoring TypeScript, adoption was somewhere in the low single digits.

What actually changed

Three things, and only one of them is about types.

Tooling stopped being the tax. For years the honest objection to TypeScript was the build setup. That objection quietly died. Modern runtimes and bundlers handle TypeScript without ceremony, and framework templates start you in it by default. You no longer opt in to TypeScript, you opt out.

Editors got good. Most of what people love about TypeScript is not type safety, it is autocomplete that knows what it is talking about, and renames that do not miss three files. That is an IDE experience, delivered by types.

AI pair programmers turned out to be type-hungry. This one surprised me. Models generate dramatically better code against a typed codebase, because the types are documentation the model cannot misread. When your function signature says what it takes and returns, an assistant does not have to guess, and you spend less time correcting confident nonsense. In a world where a real share of code is now drafted by a model, types stopped being about catching your mistakes and started being about constraining the machine's.

The part people still get wrong

TypeScript does not replace JavaScript. It disciplines it. Everything still compiles down and runs as JavaScript, and every runtime bug that was possible before is still possible now.

I have seen teams migrate to TypeScript, sprinkle any across the codebase to make the compiler quiet, and conclude that TypeScript does not help. They are right. What they built is JavaScript with extra steps and a slower build.

The value is entirely in what you refuse to let through. A codebase with strict mode on and any treated as a code smell is a different animal from one where the types are decoration.

When plain JavaScript is still the right answer

I still write plain JS, and I would push back on anyone who says you never should.

A script you will run twice and delete does not need a type system. A fifty-line utility, a one-off migration, a build hook, a quick scraper - reach for JS and move on. The setup cost, however small, is not free, and neither is the cognitive overhead of satisfying a compiler for code with a lifespan measured in hours.

My rule has not changed in years: if it has teammates, longevity, or refactors in its future, it gets types. If it has none of those three, it does not.

The trap is not choosing wrong on any single file. It is that the "quick script" quietly grows teammates and longevity while nobody is looking, and by the time it clearly needs types, it is 4,000 lines of implicit assumptions.

Migrating without stopping the world

Most teams I meet are not choosing between the two. They have a JavaScript codebase paying rent and a nagging feeling they should do something about it.

You do not need a rewrite. The path that works:

1. Turn TypeScript on with everything permissive. allowJs, no strict flags. The build should keep passing on day one. If it does not, fix that before anything else.
2. New files are TypeScript. No exceptions, no debate. This alone changes the trajectory.
3. Convert on contact. When you touch a file for a real reason, convert it. You are already reading it, and you already have the context.
4. Tighten one flag at a time. noImplicitAny first, usually. Fix the fallout, then move to the next.
5. Start at the edges. Types on your API boundaries and data models buy more safety per hour than types on internal helpers.

The teams that fail at this are the ones who schedule a Big Migration Quarter. It never survives contact with a real deadline, gets abandoned halfway, and leaves the codebase in two languages with no plan.

The honest cost

TypeScript makes you slower on the first day of a file and faster on the hundredth. If your codebase does not have a hundredth day, you are paying for insurance on a car you are about to sell.

That is really the whole calculation. Not "is TypeScript good", which is settled, but "does this code have a future long enough for types to pay back". Most production code does. Most scripts do not.

---

I work on React and TypeScript codebases that have grown faster than their architecture - migrations, performance, and the refactors nobody has had time for. Details here.

Sources: State of JS 2025 (InfoQ)