TypeScript Overtook JavaScript on GitHub: Is Pure JS Dead in 2026?

[alex_dev]

I’ve been doing web development for 7 years now, and I went through the full emotional journey with TypeScript: denial (“I don’t need types”), anger (“why is this so complicated?”), bargaining (“maybe just for big projects?”), and finally acceptance. But what really changed my mind wasn’t the type system itself—it was seeing TypeScript become GitHub’s #1 language by contributor count in 2025, surpassing both Python and JavaScript.

Why TypeScript Won

The shift happened for a few key reasons:

1. AI coding assistants love types. When I’m using GitHub Copilot or Claude, the suggestions are noticeably better in TypeScript files. The AI has more context to work with. Types aren’t just documentation for humans anymore—they’re documentation for our AI pair programmers.

2. Refactoring with confidence. Last month I renamed a core API type across our codebase. TypeScript caught 47 places where I needed to update code. In pure JavaScript, I would’ve found those bugs in production over the next two weeks.

3. Onboarding is faster. We hired 3 junior engineers this year. All of them were productive faster with TypeScript because the type errors guided them. Instead of mysterious runtime errors, they got helpful compiler messages.

4. Every major framework defaults to it. Next.js, SvelteKit, Astro, Remix—they all scaffold in TypeScript now. If you’re starting fresh, you’re probably starting with TypeScript whether you intended to or not.

When JavaScript Still Makes Sense

I’m not saying pure JS is dead. It’s perfect for:

• Quick scripts and automation
• Teaching beginners (learning syntax without type system complexity)
• Rapid prototypes where you’re exploring ideas
• Small personal projects where you’re the only developer

The Real Question

The debate isn’t “TypeScript vs JavaScript” anymore. It’s “how much type safety?” Do you enable strict mode? Do you allow ? Do you require explicit return types? These choices have real implications for team velocity and code quality.

My Prediction

JavaScript won’t die, but it’ll be relegated to specific niches—kind of like how Bash is still essential but you wouldn’t write a full application in it. For production web apps at any kind of scale, TypeScript is becoming the default.

What about you?

Are you still writing pure JavaScript for production applications in 2026? If so, what’s your reasoning? I’m genuinely curious if there are use cases I’m not considering.

[maya_builds]

Alex, this resonates so much with my experience building design systems!

Types Are Self-Documenting APIs

When we migrated our component library to TypeScript, something magical happened: our design tokens and component APIs became self-documenting. Designers could hover over a component prop in VS Code and see exactly what values were allowed. No more digging through Storybook docs or asking engineers “what color values can I use here?”

Example: Our Button component has a variant prop. In JavaScript, we had a comment that said “use primary, secondary, or tertiary.” In TypeScript, the IDE shows you those exact three options with autocomplete. Massive difference.

But… It Added Friction

Here’s the hard truth: when we went strict TypeScript, our designer contributions dropped by 60%. Designers who had been confidently tweaking component styles suddenly hit walls of type errors they didn’t understand.

Real example: One of our designers wanted to add a new icon variant. She spent 30 minutes fighting with TypeScript errors about union types and discriminated unions. She eventually gave up and asked an engineer to do it. We lost that momentum and her confidence took a hit.

The Balance We Found

After that, we created two layers:

1. Core library (strict TypeScript): Engineers maintain this. All the safety checks, proper types, bulletproof code.

2. Example code and design experiments (relaxed TypeScript): We allow any in examples, disabled strict checks for prototypes. Designers can experiment here.

The key insight: Type systems aren’t just technical decisions—they’re social ones. Your strictness level determines who can contribute. That’s not to say we should abandon types (we shouldn’t!), but we need to be intentional about the barriers we’re creating.

Agree with Your Prediction

Pure JS isn’t dead, but it’s becoming a “learning wheels” language for beginners and a “quick script” language for automation. For production systems at any scale, TypeScript is the pragmatic choice. But let’s make sure our type systems serve humans, not just machines.

What’s your team’s approach to strict mode? Do you enable all the flags, or do you dial it back for certain parts of the codebase?

[mobile_maria]

Coming from the mobile world, this debate feels very familiar. We went through the exact same evolution with Swift replacing Objective-C and Kotlin replacing Java. Now both iOS and Android ecosystems have largely moved to type-safe languages.

Type Safety Matters Even More on Mobile

On mobile, type safety isn’t just about developer convenience—it’s about battery life, memory constraints, and offline reliability. A memory leak on mobile can crash the app or drain the battery in 3 hours. Strong types help catch those issues at compile time.

But Here’s My Caution

Types don’t catch everything. Last year, we had a payment flow bug that passed all type checks in our TypeScript/React Native code. The logic was perfectly typed but fundamentally wrong—we calculated the total before applying the discount instead of after.

Result: 2 hours of incorrect charges, tons of customer support tickets, and a really uncomfortable all-hands meeting.

The Real Value of Types

For me, types are most valuable for:

1. API contracts: Mobile apps call dozens of backend endpoints. Typed API responses catch breaking changes immediately.

2. Refactoring large codebases: We have 200k+ lines of mobile code. Without types, refactoring would be terrifying.

3. Team coordination: 15 mobile engineers across 3 time zones. Types are our shared language.

Types Are Tools, Not Religion

I’ve seen engineers spend 2 hours crafting the “perfect” type for something that would work fine with a simpler approach. I’ve also seen codebases with no types that are impossible to maintain.

The sweet spot? Strong types at boundaries (APIs, public functions, component props) and looser types for internal implementation details.

To Your Question

We use TypeScript for our React Native codebase and Swift/Kotlin for native modules. Haven’t written pure JavaScript for production mobile since 2022. But we’re not dogmatic—if a script or internal tool is clearer in plain JS, we use it.

The key is intention. Choose types when they help, skip them when they don’t. But for any code that touches production or has multiple contributors, types are worth the upfront cost.

[alex_infrastructure]

Really interesting perspective, Alex. I want to add a dimension you might not have considered: TypeScript is winning because AI prefers it.

AI Coding Assistants Work Better With Types

I work in AI infrastructure, and we’ve been tracking this closely. When we migrated our internal tools from JavaScript to TypeScript, we saw a 40% improvement in GitHub Copilot suggestion quality. Not a small difference—a massive jump.

Why? Type information gives LLMs crucial context. When the model sees:

function processUser(user: User): Promise<Result> {
  // cursor here
}

It knows exactly what properties user has and what Result should contain. In plain JavaScript, it’s guessing.

The Human-AI Interface

Here’s my hypothesis: TypeScript isn’t winning just because humans prefer it. It’s winning because it’s a better interface between humans and AI.

As more code gets written by AI assistants (we’re at ~30% AI-generated code in our codebase now), the language choice becomes about what the AI can reliably produce. Turns out, typed languages lead to fewer AI-generated bugs.

Real Example

Last month, I used Claude to help write a complex data processing pipeline. I specified the types upfront:

type DataSource = { id: string; data: Buffer; metadata: Record<string, any> };
type ProcessedData = { id: string; result: string; timestamp: number };

Claude generated 300 lines of processing code. It compiled on first try and had zero runtime type errors. In JavaScript, I would’ve spent hours debugging edge cases.

The Future Implications

If AI is writing more code every year, and AI writes better TypeScript than JavaScript, then the language choice becomes obvious. It’s not about human preference anymore—it’s about human + AI collaboration.

Maybe the reason TypeScript overtook JavaScript on GitHub isn’t just developer choice. Maybe it’s developers + AI choosing together.

Question for the Community

Have others noticed AI assistants working better with TypeScript? Or is this just confirmation bias in my workflow?

[eng_director_luis]

Chiming in from the leadership perspective. We made TypeScript mandatory for our engineering team of 40+ about 2 years ago, and I can share some hard numbers.

The Business Case

Before migration:

• Production runtime errors: ~45 per week
• Average time to onboard new engineer: 6 weeks to first substantial PR
• Code review rounds: 2.8 average per PR

After migration (18 months later):

• Production runtime errors: ~31 per week (30% reduction)
• Onboarding time: 4 weeks to first substantial PR
• Code review rounds: 2.1 average per PR

The Real Cost

But here’s what the advocates don’t tell you: there’s a real productivity dip during migration. Every engineer spent their first 2-3 weeks fighting with the type system. Senior engineers adapted faster, but for some junior folks, it took a full month to feel productive again.

Why It Mattered for Us (Financial Services)

In financial services, type safety isn’t just nice to have—it’s about regulatory compliance. When we go through SOC2 audits or show our code to regulators, having strong types demonstrates rigor. It’s proof that we’re thinking about data contracts and error handling systematically.

Example: Our payment processing pipeline is entirely TypeScript with strict mode enabled. During our last audit, the reviewer specifically called out our type safety practices as a positive control.

Migration Strategy Matters More Than The Decision

The mistake I see teams make: big bang rewrites. “Let’s convert everything to TypeScript this quarter!” That’s a disaster.

Our approach:

1. New code only: All new files must be TypeScript
2. When you touch a JS file: Add basic types (no strict mode yet)
3. Critical paths first: Payment, auth, data access layers got migrated with full strictness
4. Leave the rest: That admin dashboard from 2019? Still in JavaScript. It works, we don’t touch it much, not worth the migration cost

To Your Question

We’re not writing new production JavaScript. But we have legacy JS that we haven’t migrated and probably never will. Pragmatism over purity.

The real question isn’t “TypeScript or JavaScript?” It’s “What’s the ROI of migrating this specific codebase?” Sometimes the answer is clear, sometimes it’s not worth it.