Creator of TypeScript: 10x Faster Typescript, Why AI Won't Replace SWEs | Anders Hejlsberg

Anders Hejlsberg on TypeScript’s Compiler and Why It Matters for AI Coding

Anders Hejlsberg discusses TypeScript’s compiler architecture and a recent native rewrite that made TypeScript tooling ~10x faster. He frames this as increasingly important because AI/agentic coding can trigger compile and typecheck workloads far more often.

---

Key technological concepts & product/compiler features

Why TypeScript started in JavaScript

• Early TypeScript prototypes moved to JavaScript to self-host within the JavaScript ecosystem, making the compiler and tooling usable across environments “everywhere,” including the browser.
• This was aided by improvements in JavaScript performance (e.g., V8), getting within a few multiples of native performance.
• Initial prototypes began in C (“Strata”), later evolving into a C-style implementation in JavaScript.

What’s unique about the TypeScript “compiler”

• TypeScript does not target machine code; it primarily produces JavaScript by:
  • Erasing type annotations (types are removed at runtime).
  • Performing downlevel transformations for non-evergreen JS runtimes (e.g., transforming modern standardized class behavior into older constructs like constructor functions).
• The type checker differs from typical compiler type systems:
  • It doesn’t guide runtime code generation because types don’t affect runtime behavior.
  • Types exist for tooling: IDE navigation, statement completion, refactoring, and correctness.
• TypeScript supports a gradual type system, enabling partial checking with any / unchecked regions.

What TypeScript does not optimize for

• The discussion emphasizes that TypeScript is generally designed for developer productivity and tooling, not runtime performance.
• Many workflows use TypeScript mainly for type checking, then rely on bundlers/transpilers (e.g., esbuild, SWC) to emit runnable JS.

---

Native rewrite: goals, constraints, and why Go was chosen

The problem the native rewrite solved

• Performance/scalability limits of the JS-based compiler, including:
  • A reported ~2–3x performance penalty vs native on compute-heavy workloads.
  • Limited shared-memory concurrency in JS:
    • JS effectively runs single-threaded, with parallelism via web workers.
    • Workers can’t share rich data structures without serialization (e.g., JSON), limiting efficient parallel compiler workloads.
• Motivation: modern CPUs scale via more cores, but JavaScript made compute-intensive compilation harder to scale.

Why “port” instead of “rewrite from scratch”

• Hejlsberg argues rewrites can be “toxic” due to backwards compatibility risks.
• They chose a port to preserve exact semantics and behavior of the existing compiler.

Why Go for the native compiler

Go aligned with key requirements:

• Native code generation across platforms.
• Garbage collection.
• Shared-memory concurrency support (goroutines/threads model).
• A structured port was feasible because the compiler codebase depends on GC and uses higher-order functions/closures.

Why not Rust (for this project)

• Main blockers:
  • Rust lacks built-in GC and has borrow checker limitations.
  • The TypeScript compiler uses many circular data structures (e.g., trees with parent pointers, recursive types, symbol references).
• Even if Rust were possible, porting likely required solving many additional issues beyond a pure port.

---

How LLMs/AI were used during the port

LLM usage was limited at the time

• The project started ~two years earlier, and Hejlsberg suggests LLM capabilities were significantly weaker then.

Tooling-based transformation strategy

• They:
  • Manually built critical components (scanner/parser prototypes).
  • Wrote a tool to syntactically translate TypeScript into Go, producing compilable code and then refined for correctness.
• He suggests a better future approach would be:
  • Use AI to write deterministic programs/tools that perform translations and validate outputs.
  • This is because LLM answers can be non-deterministic and risk hallucinations.

Current AI usage internally

• Use Copilot/AI for pragmatic engineering tasks:
  • Generate/fix tests
  • Assist with PR changes
  • Triage logged issues by attempting quick fixes first

---

AI/software-engineering opinions (technical framing)

• AI won’t remove humans/SWE responsibility
  • He argues “AI can do many things,” but pushing to 100% autonomy is risky:
    • someone must be accountable for failures (e.g., security incidents, correctness)
    • understanding underlying systems still matters
• Junior SWE replacement is unlikely
  • He doubts full replacement because you still need pipelines for creating/supervising senior engineers and training.
  • The work shifts toward reviewing more and typing less, with agents producing code that developers validate.
• Why compiler speed matters more with AI
  • As agents generate more code changes, teams repeatedly hit:
    • type checking / semantic analysis
    • tooling runs via language servers (LSP) or command-line compiler checks
  • If typechecking takes minutes, agent workflows become impractical—making compiler/tooling speed an AI-enablement bottleneck.

---

JavaScript vs TypeScript adoption claims

• He frames TypeScript as fixing JS tooling/ergonomics rather than replacing JS semantics.
• Claims include:
  • TypeScript became #1 language on GitHub recently.
  • “More than 50%” of GitHub JavaScript is written in TypeScript (as stated).
• He also notes AI coding tends to favor TypeScript because types help guide generation and enable static validation before runtime.

---

Practical advice / ecosystem analysis included

Flow vs TypeScript tooling

• Mentions Facebook’s Flow (camelCase) as an earlier contender.
• Flow existed, but TypeScript won by emphasizing IDE tooling integration and ecosystem contribution via self-hosting.

Why TypeScript adoption grew

• Larger codebases and increasingly advanced compiler features made type checking slower over time (e.g., TS 6 being ~50% speed of TS 1.5, per the transcript).
• CPU improvements stalled (Moore’s Law), so leveraging more cores required native shared-memory concurrency.

---

Sponsors / external products mentioned (not core tech)

• WorkOS: enterprise authentication/authorization needs via an API layer (SSO/SAML/SKIM/audit log-style requirements).
• Atlassian Jira + agents (via jira.dev/jir.dev mention): agent-based task assignment and PR generation.

---

Main speaker(s) / sources

• Anders Hejlsberg (“creator of TypeScript”) is the primary source throughout.
• The interviewer is a podcast host (name not clearly shown in the subtitles).