TypeScript Is the Default Now, Plain JavaScript Is Legacy — When Did This Happen?

[alex_dev]

I’ve been writing JavaScript professionally for over a decade. I’ve survived the jQuery era, the Angular 1 to Angular 2 migration apocalypse, the React revolution, and the great Webpack configuration wars. But nothing has shifted the ground under my feet quite like what’s happened over the last two years with TypeScript. It’s no longer a nice-to-have. It’s no longer something you “opt into.” TypeScript is just how we write JavaScript now, and if you’re starting a new project in plain JS in 2026, people look at you like you showed up to a Zoom call without pants.

The Numbers Don’t Lie

Let’s start with the hard data. According to the GitHub Octoverse 2025 report, TypeScript became the most-used language on GitHub for the first time in August 2025, surpassing even Python with 2.6 million monthly contributors. That’s not a typo — TypeScript overtook Python. TypeScript now appears in 78% of JavaScript-related job postings, up from around 60% just two years ago. Enterprise adoption has hit 78% among development teams, and TypeScript developers earn roughly $129K compared to $111K for JavaScript-only roles.

As LogRocket’s 2026 web dev trends analysis puts it bluntly: writing plain JavaScript for a professional project is now considered a “legacy approach.” TypeScript is the baseline, fueled by end-to-end type safety. Syncfusion’s frontend trends report echoes this: TypeScript has effectively become the default language of modern frontend work, especially as the line between client and server continues to blur.

The DX Revolution

What really won me over — and I’ll admit I was a skeptic until about 2023 — is the developer experience. The IntelliSense improvements alone are worth the migration cost. When I’m working with a well-typed codebase, my editor becomes a co-pilot (no, not that Copilot, though it helps too). Autocomplete is accurate. Refactoring is safe. API contracts between frontend and backend are enforced at compile time.

And speaking of AI: a 2025 study found that 94% of errors generated by AI coding assistants are type-related — exactly the kind of errors TypeScript catches before your code even runs. In an era where half our code is being suggested by Copilot or Cursor, TypeScript acts as a safety net that makes AI-assisted development actually viable. Without it, you’re just vibes-checking generated code and hoping for the best.

The framework ecosystem has unanimously voted with its feet. React documentation now shows TypeScript examples first. Next.js generates TypeScript projects by default. Vue 3 was rewritten in TypeScript with first-class support. Angular has always been TypeScript. There’s literally no major framework pushing plain JS as the recommended path.

The Overhead Is Real (But Shrinking)

I’m not going to pretend there’s zero cost. The learning curve is real, especially for developers coming from dynamically typed backgrounds. Generics still make people’s eyes glaze over. And I’ve seen teams spend more time fighting the type system than shipping features — usually because they’re trying to type everything perfectly instead of using pragmatic escape hatches.

For small projects — a quick script, a weekend prototype, a Lambda function that does one thing — plain JavaScript is still perfectly fine. I’m not going to tsc --init for a 50-line Node script. Context matters.

But here’s what’s about to change even that calculus: TypeScript 7.0, expected mid-2026, is bringing a Go-based compiler (codenamed “Project Corsa”) that delivers up to 10x faster builds, near-instant incremental compilation, and roughly 50% memory reduction. The “TypeScript is slow to set up” argument is about to evaporate. When type-checking is nearly instant, the overhead of using TypeScript even for small projects becomes negligible.

So Is Plain JS Dead?

Not dead — but it’s becoming the exception, not the rule. It’s like asking “is there still a place for writing raw SQL?” Sure, sometimes. But most of the time, you’re using an ORM or query builder because the productivity gains outweigh the overhead. Plain JavaScript is entering that same space: a tool you reach for deliberately in specific situations, not your default starting point.

The shift happened gradually, then all at once. And honestly? The JavaScript ecosystem is better for it. We spent years building increasingly complex applications in a language that couldn’t tell you a variable was undefined until your users found out in production. TypeScript didn’t replace JavaScript — it just made JavaScript grow up.

What’s your experience been? Are you all-in on TypeScript, or are there contexts where you’re deliberately choosing plain JS? I’m curious where the community draws the line.

[maya_builds]

As someone who leads a design systems team, I want to offer a perspective that goes beyond the general “TypeScript good” consensus — because in the design systems world, TypeScript isn’t just good, it’s non-negotiable.

When you’re building a component library that gets consumed by 15 different product teams, type safety for component props isn’t a luxury. It’s the difference between a Slack message at 2 AM saying “the Button component broke our build” and a red squiggly line in the editor that catches the issue before it ever gets committed. I’d estimate that TypeScript prevents about 90% of the integration bugs we used to see when teams consumed our components. Prop mismatches, missing required fields, wrong event handler signatures — all caught at compile time.

But here’s where I push back on the “more types = better” mentality: I’ve seen teams over-type everything to the point where the code becomes harder to read than the bugs it was trying to prevent. When your component prop interface is 200 lines of deeply nested generics with conditional types and mapped types and template literal types, you’ve crossed a line. The junior developer looking at that file doesn’t see safety — they see a wall of incomprehensible syntax that makes them afraid to touch anything.

The best TypeScript code I’ve seen in design systems strikes a balance. Use types where they prevent real bugs — prop interfaces, API response shapes, state management contracts. But don’t try to encode your entire business logic into the type system. TypeScript’s type system is Turing-complete, which means you can do almost anything with it. That doesn’t mean you should.

My rule of thumb for our team: if a type definition takes longer to write and understand than the runtime code it’s protecting, you’ve probably over-engineered it. TypeScript should make your code more approachable, not less. The goal is catching bugs, not winning a type gymnastics competition.

That said, I’ll take a verbose TypeScript codebase over an untyped JavaScript one any day of the week. The tradeoff math always favors type safety at scale. Just be intentional about how much type safety you’re adding and whether it’s actually serving the humans who read the code.

[mobile_maria]

Coming from the mobile world — Swift and Kotlin specifically — I have to admit my first reaction to the web’s TypeScript celebration was: “Wait, you all have been shipping production code without static types this whole time?”

In mobile development, type safety isn’t a trend. It’s been the default for as long as I’ve been writing apps. Swift’s type system catches entire categories of bugs at compile time. Kotlin’s null safety alone probably prevents millions of crashes per day across the Android ecosystem. When I first started doing cross-platform work and encountered vanilla JavaScript, I genuinely couldn’t understand how large teams coordinated without type contracts.

So from my perspective, TypeScript feels like JavaScript finally growing up and joining the rest of the programming world. The fact that it took this long is the real story, not that it’s happening now.

That said, I do have a concern that alex_dev didn’t touch on: ecosystem fragmentation. While the major frameworks have embraced TypeScript, the broader npm ecosystem is still messy. I regularly encounter libraries that either don’t have type definitions at all, have type definitions that are outdated or incorrect (looking at you, DefinitelyTyped contributions that haven’t been updated in 2 years), or have types that are technically correct but so poorly designed that they don’t actually help.

The experience of importing a library, getting a wall of any types, and losing all type safety for that integration point is deeply frustrating. It’s like having a type-safe fortress with a drawbridge that’s permanently down.

The other issue is tooling complexity. In the mobile world, Xcode and Android Studio handle compilation seamlessly — you don’t configure your type checker. On the web, TypeScript adds tsconfig.json, build step configuration, and sometimes tricky interactions with bundlers. The TypeScript 7.0 Go compiler rewrite should help enormously with speed, but the configuration surface area is still larger than I’d like.

Despite all that, I’m firmly in the TypeScript camp. The productivity gains from proper autocomplete, safe refactoring, and compile-time error catching are transformative. I just wish the web ecosystem would commit to it fully rather than leaving these half-typed gaps everywhere.

[eng_director_luis]

I want to share some concrete numbers from the trenches, because I think the TypeScript debate too often stays in the realm of vibes and preferences rather than measured outcomes.

Two years ago, I mandated TypeScript for all new projects across our engineering org — about 120 developers across 8 teams. It wasn’t a popular decision at first. Here’s what actually happened:

The costs were front-loaded:

• Onboarding time for new hires increased by roughly 20% in the first quarter. Engineers who’d never written TypeScript needed ramp-up time, and our existing team needed to develop internal conventions for how strict to be with types.
• Initial velocity on greenfield projects dropped for about 6-8 weeks while teams built muscle memory with the new tooling.
• We invested in writing a TypeScript style guide and running internal workshops. That’s real engineering hours that could have gone to product work.

The returns were dramatic and sustained:

• Bug reports related to type errors, null reference exceptions, and API contract mismatches dropped by 35% within the first six months.
• Code review cycles shortened because reviewers could trust the type system to catch a whole class of issues they used to manually verify.
• Cross-team API integration — which used to be one of our biggest sources of friction — became dramatically smoother with shared type definitions.
• New hire productivity actually improved after the initial learning curve, because well-typed codebases are essentially self-documenting. Engineers could explore unfamiliar code through types rather than hunting through documentation or Slack messages.

The ROI is clear for teams operating at scale. This is not a close call anymore.

But here’s my nuance: for solo projects, prototypes, or quick automation scripts, I still reach for plain JavaScript. When I’m writing a one-off Node script to process some CSV data, I don’t need type safety — I need to be done in 20 minutes. When I’m hacking on a weekend side project, I don’t want to think about tsconfig.json strictness settings.

The mistake I see in these discussions is treating it as a binary: TypeScript or JavaScript, pick a side. The right answer is context-dependent. TypeScript is the correct default for professional, team-based software development. Plain JavaScript is a perfectly valid choice for scripts, prototypes, and solo experiments.

The problem with dogma is that it replaces thinking. Use TypeScript where the type safety genuinely improves outcomes. Use plain JS where the overhead exceeds the benefit. But if you’re building a production application with a team in 2026 and you’re not using TypeScript, you should have a very specific reason — because the default has clearly shifted.