JavaScript Is Out, TypeScript Is In

JavaScript is far from dead, but its job description has changed. For much of modern web development, TypeScript has become the default way to write JavaScript, even though the code that ships is still plain JavaScript underneath.

That shift appears across React, Vue, Angular, Node.js, monorepos, mobile apps, desktop apps, and even the application layer around AI. The real question is no longer whether people use JavaScript. It is where raw JavaScript still fits best and why so many projects now start with TypeScript instead.

I also created a YouTube video on this topic.

TypeScript Has Become the Default Across the Modern Stack

A big part of the answer is scale. GitHub's 2025 Octoverse report says TypeScript became the number-one language on GitHub by monthly contributors, passing both Python and JavaScript. The 2025 State of JavaScript survey found that respondents spent 77% of their JavaScript and TypeScript coding time writing TypeScript.

That does not mean TypeScript replaced JavaScript. GitHub still saw more new JavaScript repositories overall. But the trend is clear: TypeScript has become the normal choice for modern application development, especially once a project grows beyond a tiny script.

React, Vue, Angular, and Node.js Have Made Typed Workflows Feel Standard

The front end is where the shift feels most visible. React supports TypeScript fully, Vue is written in TypeScript and supports it first class, and Angular has used TypeScript classes for components since Angular 2. You can still write regular JavaScript with React or Vue, but a new app created with Vite or another CLI usually comes with TS and TSX files by default.

The back end has moved too. Node.js can run TypeScript files directly by stripping the types and executing JavaScript underneath. That becomes especially useful in a monorepo, where the front end, an API, a background worker, and a shared package all live together. Instead of defining a user, product, or API response in three different places, you define it once and reuse it everywhere.

A few patterns make that appeal especially clear:

1. Shared types reduce duplication across client, server, and worker code.

2. Zod lets you define a schema once, infer TypeScript from it, and validate real data at runtime with the same source of truth.

3. React Native projects now often default to TypeScript for mobile work.

4. Electron templates commonly use TypeScript for desktop apps.

5. Vercel's AI SDK puts TypeScript at the center of AI application code.

Taken together, TypeScript is not just a nicer editor experience. It has become a shared language across a huge part of the application stack.

TypeScript Won Because It Made JavaScript Feel Safer and More Legible

The appeal is not mysterious. TypeScript brought ideas developers already knew from languages such as Java, C, and C++ into the JavaScript world. That mattered when JavaScript still had a reputation as a toy language mostly used for form validation and dropdowns.

The practical benefits are what keep people using it:

• Renaming a shared field, such as changing name to fullName, can instantly reveal every component, API route, or function that still depends on the old field.

• Autocomplete becomes more accurate because the editor understands what a function expects.

• Types act like contracts, helping different pieces of the codebase describe how they fit together.

• Refactors become safer because you can jump to definitions and rename things across a project with more confidence.

There is also less friction than there used to be. Frameworks, libraries, and build tools now support TypeScript extremely well, and its inference has improved enough that you often get strong type checking without annotating everything manually. You can gain better autocomplete, safer refactors, and clearer feedback without turning the project into a ceremony festival.

It's just one more useful layer of feedback.

That matters even more when AI is writing part of the code. An agent can still produce perfectly typed garbage, so TypeScript should never replace tests or code review. It simply provides another check on top of the others.

Learn JavaScript First, Then Add TypeScript When the Project Earns It

Beginners should still learn JavaScript first. If the goal is web development, skipping straight to TypeScript syntax is backwards. Learn functions, objects, arrays, scope, asynchronous JavaScript, the DOM, and how the language behaves at runtime before adding another layer.

That foundation matters because weird TypeScript bugs are usually JavaScript problems in disguise. Once those fundamentals are solid, TypeScript becomes the next step, not the first step. You do not need to become a type-system wizard. You only need to recognize the types you will encounter in real projects and learn how to read the errors.

JavaScript still has real jobs that TypeScript does not always improve. Plain JavaScript can be the better choice when the work is small, quick, or intentionally simple:

1. A tiny script or quick prototype often does not need the extra setup.

2. A low-code project can move faster without types getting in the way.

3. Teaching fundamentals is sometimes easier when the type system is not clouding the lesson.

4. A one-off file that only needs a few lines and a run command can be better left alone.

Choosing JavaScript does not make the work amateurish. It means the tradeoff makes sense. TypeScript adds value, but it also adds concepts, configuration, and another class of errors to understand. Use JavaScript when simplicity wins, and reach for TypeScript when the project has enough moving parts to deserve the extra structure.

JavaScript still powers the web, but TypeScript now shapes how a huge part of the ecosystem gets built. The smartest choice is not picking a side. It is knowing when the typed version earns its keep.

This article was adapted from Does Anyone Use JavaScript Anymore?.