TypeScript Just Became GitHub’s #1 Language: Here’s Why

TypeScript’s rise on GitHub is a meaningful signal, but not for the reasons some headlines suggest.

This shift does not mean JavaScript is disappearing. Browsers still run JavaScript. Node.js executes JavaScript directly, while TypeScript usually needs to be compiled before execution. What’s changing is how professional teams prefer to write JavaScript, especially as applications grow larger, teams scale, and AI tooling becomes part of everyday development.

GitHub’s Octoverse 2025 report says TypeScript overtook both Python and JavaScript in August 2025 to become the most-used language on GitHub in that reporting context, while also noting that Python remains dominant for AI and data science workloads and that the JavaScript/TypeScript ecosystem still accounts for major overall activity.

So, the practical takeaway is: TypeScript is not replacing JavaScript as the web’s runtime language. It is becoming the preferred authoring experience for many modern JavaScript projects.

Let’s look at what changed!

What GitHub ranking actually represents

Before reading too much into the ranking, it helps to understand what GitHub measured.

GitHub’s Octoverse language ranking should be interpreted as a platform activity signal, not as proof that TypeScript is the most executed language, the language with the most total code, or the runtime foundation of the web. GitHub reports that TypeScript overtook Python and JavaScript in August 2025 as part of its Octoverse analysis.

In August 2025, TypeScript overtook both JavaScript and Python by this metric. Python and JavaScript did not collapse; they simply grew more slowly.

The takeaway is not “TypeScript replaced everything,” but rather:

More active development work on GitHub is moving toward TypeScript, especially in application development, frontend frameworks, full-stack JavaScript projects, and AI-assisted workflows.

That alone makes it worth paying attention to.

Why TypeScript scales better than plain JavaScript

JavaScript’s flexibility is one of its strengths, but that same flexibility becomes harder to manage as applications grow.

In small projects, assumptions about data shapes, component props, or API responses are easy to hold in your head. In large, shared codebases, those assumptions become fragile.

For example, this JavaScript function looks simple:

function formatUserName(user) {
    return `${user.firstName} ${user.lastName}`.trim();
}

But several questions are hidden:

• Is the user always defined?
• Is firstName always present?
• Is lastName optional?
• What happens if the API returns first_name instead of firstName?

TypeScript helps by turning implicit assumptions into explicit contracts. Types make it clear:

• What a function expects
• What it returns
• Which properties are optional
• Where changes ripple through the system

These guarantees exist at compile time. Runtime data from APIs, databases, forms, or third-party services must still be validated separately.

A TypeScript example:

type User = {
    firstName: string;
    lastName?: string;
};

function formatUserName(user?: User): string {
    if (!user) return "";  
    return `${user.firstName} ${user.lastName ?? ""}`.trim();
}

This version demonstrates both explicit object shape and defensive handling when user may be missing. TypeScript can help catch missing or incorrect properties during development, while the runtime guard handles the case where no user object is passed.

That clarity reduces coordination cost across teams. Instead of discovering mismatches during QA or after deployment, developers catch them as they write code.

Tooling and developer experience matter more than ever

TypeScript is not just about safety. It significantly improves everyday developer workflow.

With type information, editors like VS Code provide:

• More accurate autocomplete
• Safer refactoring
• Inline error detection
• Better navigation and API discovery

For many teams, this is where TypeScript pays for itself. The code becomes easier to change, not just safer to run.

AI coding assistants made types more valuable

One of the most important accelerators behind TypeScript’s growth is AI-assisted development.

AI coding tools perform better when they have structure. Clear type information gives both humans and AI systems better context about inputs, outputs, and data relationships.

Compare this function signature:

function getUserProfile(userId: string): Promise<UserProfile>

With an untyped version:

function getUserProfile(userId)

The TypeScript version tells the developer and the AI assistant:

• userId must be a string
• The function returns a promise
• The resolved value should match UserProfile

That reduces ambiguity.

GitHub’s Octoverse 2025 report connects TypeScript’s rise with broader shifts in AI-assisted development and typed language adoption, but this should be read as a strong trend signal rather than proof of direct causation. Typed languages like TypeScript can improve AI-assisted development by providing a clearer structure, which may help surface generated-code issues earlier.

In the AI era, type safety is not only about productivity. It can also support reliability when combined with testing, code review, and runtime validation.

Is JavaScript dead? No.

JavaScript is still the runtime foundation of the web. Browsers execute JavaScript. Node.js executes JavaScript directly, and TypeScript commonly compiles to JavaScript before running in production environments.

What’s changing is the authoring experience. Many teams now prefer to write TypeScript because it better matches how modern applications are built: larger codebases, shared ownership, frequent refactoring, and automated tooling.

JavaScript knowledge still matters deeply: closures, async behavior, modules, performance, and browser APIs remain essential. TypeScript doesn’t replace those fundamentals; it formalizes them.

What this means for JavaScript developers

For JavaScript developers, the takeaway is practical rather than alarming.

Learning TypeScript does not require rewriting everything or mastering advanced generics immediately. Most developers become productive by focusing on a small set of concepts:

• Type annotations
• Interfaces and type aliases
• Optional properties
• Union types
• Basic generics
• unknown vs any
• Type narrowing

The fastest way to learn is to convert real code: small utilities, API clients, or components rather than memorizing syntax in isolation.

A practical JavaScript-to-TypeScript migration plan

TypeScript adoption works best when it’s gradual. Instead of rewriting an entire JavaScript project, start with type checking, convert low-risk files first, and tighten compiler rules over time.

For a deeper walkthrough, refer to the official TypeScript documentation: Migrating from JavaScript.

Start by installing TypeScript as a development dependency:

npm install --save-dev typescript

Then create a TypeScript configuration file:

npx tsc --init

Follow this gradual migration path:

• Start with low-risk files: Begin with utilities, constants, helpers, API wrappers, or small components. These offer quick wins without destabilizing the application.
• Define shared domain types: Create clear types for common entities like users, orders, or roles. Good domain types make the rest of the codebase easier to understand and maintain.
• Use allowJs for incremental migration: TypeScript’s allowJs option supports mixed codebases, allowing existing JavaScript files to coexist with TypeScript while teams migrate gradually. The TypeScript migration guide specifically shows allowJs as part of a JavaScript-to-TypeScript setup.
• Use checkJs when you are ready to type-check JavaScript files: checkJs works with allowJs and reports errors in JavaScript files. This can help teams find issues before renaming files from .js to .ts.
• Avoid overusing any: any can unblock progress, but overuse removes most of TypeScript’s value. When the shape of data is unknown, prefer unknown and narrow it safely.
• Start loose, then tighten strictness: Starting with “strict“: false can reduce migration friction in large projects, but teams should plan to enable strict mode incrementally. Strict checking unlocks much of TypeScript’s safety value.
• Add Type checking to CI: Running tsc --noEmit in CI ensures type safety becomes part of the workflow, not an afterthought. For cleaner CI logs, teams can also use tsc --noEmit --pretty false.

A conservative migration-friendly tsconfig.json can start like this:

{
    "compilerOptions": {
        "allowJs": true,
        "checkJs": true,
        "noEmit": true,
        "strict": false
    },
    "include": ["src"]
}

This configuration allows JavaScript files into the TypeScript project, enables checking for JavaScript files, avoids emitting compiled files during type checks, and keeps strict mode off initially to reduce migration friction. As the codebase becomes more typed, enable stricter options gradually.

For more details about compiler options such as allowJs, checkJs, noEmit, and strict, see the official TSConfig reference.

Next, add a repeatable type-check script to package.json:

{
  "scripts": {
    "typecheck": "tsc --noEmit --pretty false"
  }
}

Then run:

npm run typecheck

If you are migrating an existing JavaScript project, avoid treating it as a full rewrite. TypeScript can be introduced gradually, and the official TypeScript migration guide explains how to set up a JavaScript codebase for TypeScript, configure tsconfig.json, use allowJs, and move files step by step.

Where TypeScript does not help

TypeScript is powerful, but it has limits.

• It does not validate runtime data from APIs.
• It does not fix poor architecture.
• It does not replace testing.
• It does not guarantee that third-party data matches your declared types.

External data still needs runtime validation. Business logic still needs tests. Good system design still matters. TypeScript works best alongside clear boundaries, validation, and automated testing, not instead of them.

TypeScript won the default, not the web

TypeScript’s rise on GitHub reflects how many professional teams build software today. JavaScript remains the platform. TypeScript increasingly serves as the structured, scalable way to write JavaScript applications.

For JavaScript developers, the path forward is straightforward:

• Learn TypeScript gradually
• Apply it where it adds clarity
• Keep validating data at runtime
• Keep writing tests
• Tighten compiler settings over time.

The future is not less JavaScript. It is better-structured JavaScript. For many teams, that structure now comes from TypeScript.

Practical next step

You don’t need a full migration to start seeing value from TypeScript. Try this week:

1. Convert one small JavaScript file to TypeScript.
2. Add a type for one API response.
3. Replace one unsafe any with unknown.
4. Run npx tsc --noEmit.
5. Use tsc --noEmit --pretty false in CI if you want cleaner logs.
6. Add runtime validation for one external API response.

You’ll learn more by converting real code than by reading another syntax guide.

Related Blogs

Better Auth: Framework-Agnostic Authentication Solution for TypeScript Apps

9 min read

TypeScript Generics: A Complete Guide

7 min read

TypeScript Utility Types: A Complete Guide

11 min read

Top Linters for JavaScript and TypeScript: Simplifying Code Quality Management

10 min read