Does Anyone Write JavaScript Anymore?

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

That shift shows up everywhere: 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 simple 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 obvious: TypeScript has become the normal choice for modern application development, especially once a project starts growing 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 really clear:

1. Shared types cut 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 right at the center of AI application code.

Once you stack all of that 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 that developers already knew from languages like Java, C, and C++ into the JavaScript world. That mattered a lot when JavaScript still had a reputation as a toy language, mostly good for form validation and dropdowns.

The practical wins are what keep people using it:

• Renaming a shared field, like 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, so different pieces of the codebase describe how they fit together.
• Refactors get 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. That means you can pick up better autocomplete, safer refactors, and clearer feedback without turning the whole project into a ceremony festival.

It's just one more useful layer of feedback.

And 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 just gives you 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 layering anything on top.

That foundation matters because weird TypeScript bugs are usually really 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 just need to recognize the types you will see in real projects and learn how to read the errors.

Still, JavaScript 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 just 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?.