TypeScript Is Great. So Why Is JavaScript Still Everywhere?

TypeScript became the most-used language on GitHub in August 2025 — overtaking Python and JavaScript for the first time in over a decade [4]. 78% of professional developers now write TypeScript [5]. And yet, open almost any legacy codebase, startup MVP, or quick utility script and you’ll still find plain .js files staring back at you. That’s not laziness. There are real, structural reasons for it.

What Is TypeScript, Actually?

TypeScript is JavaScript with types bolted on. Microsoft built it to address a real problem — large JavaScript codebases become unmaintainable fast. When a codebase has tens of thousands of lines and dozens of contributors, you can’t know what a function expects just by reading a call site [1].

The core idea is static typing. In JavaScript, you find out that you passed a string where a number was expected at runtime — when the bug is already in production. TypeScript catches that at compile time, before anything runs [2].

// TypeScript
function add(a: number, b: number): number {
  return a + b;
}

add(5, "10");  // ❌ Error: Argument of type 'string' is not assignable to parameter of type 'number'

// JavaScript
function add(a, b) {
  return a + b;
}

add(5, "10");  // ✅ No error. Returns "510". Good luck debugging.

That’s the whole pitch in two code blocks.

One important thing: TypeScript is not a different runtime. The browser never sees a .ts file. TypeScript compiles down to plain JavaScript. At runtime, it’s all just JS anyway [1].

What TypeScript Actually Gets Right

Errors before they reach users

This is the biggest one. A type mismatch, a missing property, a function called with wrong arguments — all of these get caught during the build step, not in a production error log at 2 AM [2].

IDE superpowers

Autocomplete in a typed codebase is actually useful. Jump to definition works. Refactoring a function name doesn’t leave orphan references all over the place. With JavaScript, your editor is mostly guessing [9].

Self-documenting code

interface User {
  id: number;
  name: string;
  email: string;
  isAdmin: boolean;
}

function getUser(id: number): Promise<User> { ... }

You don’t need a comment explaining what this function does or returns. The types tell you. In a team of 5+ developers, this is worth a lot [2].

The numbers back it up

TypeScript adoption crossed 75% of active npm packages in 2025 [8]
85% of the top 1000 npm packages now ship with TypeScript type definitions [5]
Developer satisfaction sits at 84.1% — highest of any language surveyed [3]
A 2025 academic study found 94% of LLM-generated compilation errors were type-check failures — meaning AI coding assistants produce better output when paired with TypeScript [5]

That last one is interesting. As AI writes more code, typed languages become even more valuable as a safety net.

ts vs js comparison

So Why Do So Many Apps Still Use JavaScript?

This is the honest part. There are five real reasons — not excuses.

1. Most of the web was already written before TypeScript mattered

TypeScript was released in 2012. It took years to gain serious traction. Millions of production apps were built in JavaScript before TypeScript became the default. Rewriting a working codebase is expensive and risky. Companies don’t do it unless there’s a strong business case. So those codebases stay in JavaScript — and keep getting maintained in JavaScript [10].

2. The build step is a real cost

JavaScript runs directly in the browser. TypeScript doesn’t. You need a compiler (tsc, or esbuild, or swc, or babel, or something else), a tsconfig.json, a build pipeline, and someone who understands why the build broke [6].

For a team building a quick internal tool or a weekend project — that overhead feels pointless. And it often is pointless at that scale [7].

3. TypeScript’s types are optional and imperfect

Here’s something people don’t talk about enough: TypeScript’s type system does not guarantee runtime safety. You can cast anything to any. You can use @ts-ignore. External API responses are unknown until you tell TypeScript what they are — and if you lie, TypeScript believes you.

const data = await fetch('/api/user').then(r => r.json()) as User;
// TypeScript trusts you. If the API returns something different, you still crash.

For teams that don’t enforce strict mode, TypeScript projects can end up being JavaScript with extra noise [2].

4. Not all libraries have great TypeScript support

The @types/* packages on DefinitelyTyped help, but they’re maintained by volunteers and lag behind library updates. If you’re using a niche library, you might spend more time fighting missing or wrong type definitions than writing actual code [6].

5. Small scripts don’t need this

A 50-line Node.js script that reads a CSV and uploads to S3. A browser snippet that toggles a class. A serverless function that sends one email. TypeScript’s value scales with project size and team size. Below a certain threshold, it’s just noise [7].

Where the Line Is

Scenario	JS or TS?
Personal script / one-off utility	JavaScript
Solo MVP, proof of concept	JavaScript (or TS if already set up)
Team project, 3+ developers	TypeScript
Long-lived production app	TypeScript
Public npm library	TypeScript
Framework internals (e.g. Svelte compiler)	Sometimes JSDoc-annotated JS [10]

Svelte is an interesting case. The Svelte team actually converted their compiler’s own source from TypeScript back to JSDoc-annotated JavaScript in 2023 — not because TypeScript is bad, but because it removed the build step from their development loop while keeping type hints via JSDoc. Svelte still fully supports TypeScript for applications built with it [10].

TypeScript Is Winning — Just Slowly

The migration isn’t theoretical. It’s happening. 40% of developers now write exclusively in TypeScript, up from 28% in 2022 [3]. Major frameworks ship TypeScript-first by default — Next.js, Nuxt, SvelteKit, Angular [8]. You essentially cannot write Angular without TypeScript at this point.

The AI coding wave is accelerating this. When your AI assistant generates code, you want a type system to catch the mistakes before you ship them [5].

JavaScript will still be around for a long time — the existing web doesn’t rewrite itself. But for new projects of any real scale, the default has shifted. You’d need a specific reason to not use TypeScript now, not a reason to use it.

End