Published on

Looking Beyond TypeScript: Programming Language Trends in the AI Era

AI-assisted translation from ChineseRead the original in Chinese

Authors

@Author: Garfield Zhu

English edition: AI-assisted translation from the Chinese original.

Quote: Ten years ago, when I checked technical forums every week, the rises and falls of different languages on the TIOBE Programming Language Index were always an interesting topic. I had to look at it once a month. It ranked influence and popularity—or, more precisely, search volume. Java, C, and later Python topped it year after year. They were both the easiest languages to find a job with and the ones people criticized most. After all, hate-driven traffic is still traffic. Languages used by fewer people naturally attract fewer bad reviews, and may instead produce better languages. Later, the reports published by GitHub Octoverse came closer to what people were actually writing and committing. Last year's 2025 report reflected a fascinating trend: TypeScript decisively took the top spot as the most-used language, even pulling far ahead of Python, the leading AI language before the era of LLMs. That is certainly worth thinking about.

Yes, TypeScript was GitHub's most-used language in 2025—not Java, the language with the most users; not JavaScript; and not Python, the king of AI across machine learning and Transformers. It was TypeScript: once thriving in the era of the web frontend, yet seemingly never truly surpassing JavaScript itself.

I have to admit that I was somewhat surprised. For me, it may already be one of the languages I write most often—possibly because of the damn workload of React and its complex component types. I have also written TypeScript posts about type gymnastics and practicing functional programming. Personally, I consider it, alongside VS Code, one of Microsoft's most outstanding and likability-boosting achievements of the new era.

But I also believed it would never become a breakout language, let alone number one. After all, the community conversation had already begun to ebb more than three years ago. I first noticed the mental burden TS's complexity and constraints impose on developers in DHH's 2023 blog post—DHH being the author of Ruby on Rails—Turbo 8 is dropping TypeScript. As the true god of the Ruby world, DHH's understanding of interpreted languages requires no questioning. His criticism and abandonment of TS, along with the "Farewell, TypeScript" wave in the community at the time, were all well grounded. If it ultimately became any-script, it would merely be JavaScript with a worse experience and extra compilation time.

Perhaps lighter approaches such as JSDoc, which are closer to native JavaScript and involve fewer tradeoffs, would bring TypeScript to an end... maybe?

Clearly, three years later, things have developed in the completely opposite direction. TypeScript has become the undisputed king of the AI era. The discussion under the PR where DHH's Turbo project removed TypeScript is still well worth revisiting today—not to decide who was right, but simply to consider what significance the arguments have now.

DHH's TypeScript-to-JavaScript illustration

Why TypeScript

These days, I can hardly even find the mixed TS + JS projects that used to be common. AI is simply too good at handling type systems. Type inference is an exceptionally deterministic reasoning process. Conversely, clearly defined input and output types in context give AI explicit constraints and reduce ambiguity during implementation.

By contrast, the similar type completion and IDE warnings provided by JSDoc are meant for humans. Agents cannot perceive its existence; the semantics it provides to an Agent are no different from comments written in natural language. It may even become additional contextual overhead, and as a comment, it can easily be discarded during context compression.

/**
 * @param {User} user
 */
function save(user) {}

What AI Has Brought

  • Without question, AI's ability to understand and reason about type systems lets the advantages of statically typed languages fully show up during development. In vibe coding, the reasoning cost is also noticeably lower than with weakly typed languages.
  • The compiler is an efficient, low-cost verification tool for AI. Compile-time type errors expose many problems early instead of waiting for runtime. Weakly typed languages can of course still produce correct code with AI's help, but ambiguous types make latent runtime errors easier to introduce; those issues often surface only when Playwright runs automated tests, making the discover → fix → rerun loop expensive.
  • Agents give statically typed languages a fast, cheap loop: “generate → compile (type-check) → report error → fix → compile again → pass.” For multi-round repair, time cost depends on compilation speed; type errors are usually precise enough to understand without much context, significantly reducing total time and token cost.

What Agents Need

For a long time, AI was almost synonymous with Python. From PyTorch, TensorFlow, NumPy, and Pandas to CUDA, Python was nearly dominant. In the LLM era that began with ChatGPT, Python remains core.

But Agents also created huge software ecosystem needs beyond the LLM itself:

  • From LLM APIs, tool calling, MCP, and Agent Skills to Harness, the way we call and manage LLMs keeps evolving. Besides adding stronger features, this raises the bar for the surrounding software ecosystem.
  • From Cursor and Claude Code to Codex, cross-platform AI coding assistants keep appearing, pushing demand for a more efficient and intelligent ecosystem. CLI, TUI, App, and plugin forms have all found audiences. OpenCode, PI, DeepSeek Harness, and other open-source Agents are also driving growth throughout the ecosystem.
  • Modern AI apps need to manage LLM, Tools, MCP, and DB services on the server, and provide interfaces for web apps, client applications, and VS Code plugins. Conveniently, Web, Electron/Tauri, and Node.js are all in TypeScript's comfort zone.
  • TypeScript + Zod provide schemas. LLM output contracts, API payloads, tool and MCP parameter/output formats, and so on all need explicit schemas. When schemas are generated from TypeScript and validated, compile-time types, runtime JSON Schemas, and LLM output formats can share one unified contract. The value is obvious.
  • A single npm package distributed to both frontend and backend is pleasantly easy too.

That makes TypeScript a natural choice for modern, AI-driven, multi-platform application development.

Right on Time: A Faster TypeScript

As someone who got into TypeScript in the 2.x era, I followed many of its syntax updates—especially the question-mark bundle (optional chaining ?. and nullish coalescing ??). Most of my projects today are still on 5.x, though, because it is mature, both in its type system and in the features it delivers ahead of the ES standard.

That said, the Go-based TypeScript 7 really is fast. It is so fast that it genuinely matters. Unlike large C++ or Rust projects, whose full compilations can take tens of minutes or even hours, reducing tsc's compilation time from 60 seconds to 10 seconds is a major improvement. This is especially valuable for Agents operating under Loop Engineering: they can iterate more quickly through modify → verify → modify, and more easily understand the impact of type errors.

A tsc with a clearly lower invocation cost will also substantially increase an Agent's willingness to call the tool, which in turn will influence Harness design.

The only reason I currently lack the motivation to upgrade old projects to TS7 is that @7.0.2 only ships the compiler, tsc, and does not yet provide an API. Tools such as typescript-eslint that need to access the compiler through its API cannot use TS7, and still need to use the TS6.0 API.

So for now, your package.json still needs to use the 7.0 tsc this way, while the tooling continues to use 6.0:

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

So, Microsoft, could you please hurry up with TypeScript 7.1?

What We Used to Write

Historically, adding more modern syntax sugar was often the most prominent and eye-catching part of a language's release notes. The old Java language stuffed private methods into interfaces, then added var, record, and text blocks—enough to make Java 8 programmers see double. So learning to use advanced syntax to take shortcuts and increase code information density is an important way to make human programmers more productive.

Compared with old languages struggling to improve, the languages that feel best to write are efficient and easy to use; JS and Python are obvious standouts. Most of the time, people are willing to trade away some language performance for development efficiency.

So What Is AI Good At, and What Should It Write?

AI is good at handling large amounts of structured and unstructured data, and even better at reasoning through complex logical relationships. That makes the compiler of a statically typed language a powerful tool for AI.

Likewise, Rust is a very interesting language. Its compile-time lifetime and ownership checks provide memory safety and data-race freedom in safe code, but getting code through its compiler is considerably harder than with other languages. That difficulty creates a substantial cognitive burden for human programmers. For AI, however, reasoning about ownership and lifetimes is similar to type inference and comparatively easy. With detailed compiler errors (for example, value borrowed here after move), AI can quickly locate and fix problems. The modify → compile-and-verify → modify flywheel can therefore run efficiently in Rust too, while bringing strong memory-safety guarantees. Strong data-race guarantees also help AI detect potential data races at compile time, reducing the pressure on end-to-end concurrency tests.

As a more modern language, Rust also has a more self-consistent and complete toolchain. Standardized tooling, rather than third-party libraries, gives Rust projects a consistent workflow:

cargo check
cargo fmt
cargo clippy
cargo test
cargo doc

Agents therefore spend less context investigating and learning toolchains. There is no need to guess between pip and uv or webpack and Vite; they can simply follow standardized toolchain commands.

Timing and Fate

Turbo is still a good project. It enables extremely fast SPA development, has a conspicuous 100% JavaScript language bar, and a pile of closed PRs such as "Add TypeScript back."

Only three years have passed since 2023. Back then, ChatGPT had been released for only a few months. People were still discussing the first year of generative AI. There were no Agents or vibe coding yet, and nobody was handing their code over to AI. The frontend world was still flourishing, decked out in flowers and blazing with prosperity.

And now, frontend is probably already dead...