TypeScript: Is It Really Being Phased Out?

Though it’s a slightly older story, a heated debate has been taking place in the developer community. Sparked by David Heinemeier Hansson (DHH), the creator of Ruby on Rails, removing TypeScript from the hotwired/turbo project, the controversy has led to a fundamental question: “Do we really need TypeScript?”

Since its release by Microsoft in 2012, TypeScript has become known as a tool that adds static types to JavaScript, enhancing maintainability in large-scale projects. However, after DHH’s decision, other projects like Svelte also began reconsidering TypeScript usage, leaving many developers feeling confused.

In this post, we’ll explore the pros and cons of TypeScript and provide criteria to help you determine whether it’s the right fit for your project.

DHH: Turbo 8 is dropping TypeScript

Arguments Against TypeScript

Why DHH Removed TypeScript from Turbo 8

In his blog post, Turbo 8 is dropping TypeScript, DHH openly explains the reasoning behind his decision. To summarize his points:

“TypeScript adds friction instead of joy to my development experience. It requires an explicit compilation step and pollutes the code with type gymnastics. Things that should be easy become hard, and the hard things end up becoming any.”

DHH argues that JavaScript, especially after ES6, is now a mature enough language. Features like class syntax and various improvements make JavaScript itself enjoyable to work with—no additional tooling needed.

Code Pollution and Complexity

One of the most common criticisms of TypeScript is “code pollution.” Simple JavaScript code becomes cluttered with verbose type annotations, harming readability.

// TypeScript
function processUser(user: User & { permissions: Permission[] }): Promise<ProcessedUser | null> {
  // implementation
}

// JavaScript
function processUser(user) {
  // implementation
}

As shown above, TypeScript requires additional code for type definitions. In small projects or during prototyping, these types can actually slow down development.

Compilation Time and Build Process

Because TypeScript can’t run directly in the browser, it needs to be compiled to JavaScript. As the project grows, compilation time increases, adding friction to the development workflow.

DHH emphasizes that “JavaScript is a language meant to run in the browser,” and being able to code freely without tools is a huge advantage.

Arguments for TypeScript

Maintainability and Scalability

TypeScript’s biggest strength lies in its maintainability in large projects. The type system clarifies developer intent and helps catch refactoring errors early.

interface UserProfile {
  id: string;
  name: string;
  email: string;
  createdAt: Date;
}

function updateUserEmail(profile: UserProfile, newEmail: string): UserProfile {
  return {...profile,email: newEmail
  };
}

If the UserProfile interface changes, TypeScript immediately shows all affected code—no need to check hundreds of files manually.

Fewer Bugs and Increased Stability

In JavaScript, type errors occur at runtime, meaning users can encounter them in production. TypeScript catches these issues during compilation.

function calculateTotal(price: number, quantity: number): number {
  return price * quantity;
}

calculateTotal("100", 5); // Compile error: string is not assignable to number

One developer noted, “In large projects, TypeScript is essential for building a stable development environment.” In enterprise settings, early error prevention is crucial.

Team Collaboration and Developer Experience

TypeScript enhances IDE support with autocompletion, refactoring tools, and real-time error detection. In team projects, type definitions serve as live documentation for understanding each other’s code.

/**
 * Validates and processes user data
 */
function validateUser(user: User): ValidationResult {
  // The IDE autocompletes all properties of User
  if (!user.email.includes('@')) {return { valid: false, error: 'Invalid email' };
  }
  return { valid: true };
}

New team members can understand a function’s input and output just by looking at its type definitions.

Value in Enterprise Environments

TypeScript shines in projects with complex business logic or large developer teams. In such long-term codebases, type safety becomes critical.

This is why major companies like Microsoft, Google, and Airbnb have widely adopted TypeScript.

Community Reactions

Mixed Opinions

DHH’s removal of TypeScript sparked debate across the developer community. The Korean community also showed strong divisions:

Supporters of Removal:

• “TypeScript is overengineering for small projects.”
• “JavaScript’s flexibility is better than TypeScript’s rigidity.”
• “No compile step means faster development.”

Opponents:

• “Large projects are unmaintainable without TypeScript.”
• “Type safety is a must, not a choice.”
• “Though the learning curve is steep, it pays off in the long run.”

When the removal was merged into Turbo, reactions were largely negative. Many developers expressed concern.

Comments from YouTuber 조코딩 (Jocoding)

Well-known YouTuber 조코딩 noted that “Svelte also dropped TypeScript,” citing productivity loss as the main reason. This reflects a trend where some frameworks are starting to make TypeScript optional—or removing it altogether.

JSDoc as an Alternative

JSDoc is often mentioned as a lightweight alternative to TypeScript. It adds type hints via comments:

/**
 * @param {string} name - User name
 * @param {number} age - User age
 * @returns {Object} User object
 */
function createUser(name, age) {
  return { name, age };
}

JSDoc can provide type hints without compilation, but it lacks TypeScript’s powerful checks and IDE support. Many developers feel, “If you’re going to use JSDoc, you might as well use TypeScript.”

The Future of JavaScript and TypeScript

ECMAScript Type Annotations Proposal

Interestingly, the ECMAScript TC39 committee is currently reviewing a proposal to add type annotations directly to JavaScript. Currently in Stage 1, this proposal could allow native type syntax.

// Future JavaScript?
function add(a: number, b: number): number {
  return a + b;
}

These type annotations would be ignored at runtime, meaning they’d run directly in the browser—potentially offering type safety without TypeScript’s compilation step.

Coexistence Seems Likely

Even if type annotations are added to JavaScript, TypeScript won’t disappear. It offers far more than just type syntax:

• Advanced type system: Generics, union/intersection types
• Type inference: Automatically infers types
• Decorators: For metaprogramming
• Strict checks: Fine-grained compiler control

If the proposal is adopted, TypeScript may become a tool for projects needing advanced type features.

Framework and Library Adoption

Major frameworks like React, Vue, and Angular officially support TypeScript. React’s documentation recommends using it.

// React with TypeScript
interface ButtonProps {
  onClick: () => void;
  children: React.ReactNode;
  disabled?: boolean;
}

const Button: React.FC<ButtonProps> = ({ onClick, children, disabled = false }) => {
  return (<button onClick={onClick} disabled={disabled}>  {children}</button>
  );
};

Meta-frameworks like Next.js and Remix also treat TypeScript as a first-class citizen, often with default configuration.

Given these trends, TypeScript seems likely to remain mainstream for now.

Is TypeScript Right for Your Project?

When to Use TypeScript

Consider TypeScript if your project matches any of the following:

Large or long-term projects:

• 10+ modules interacting
• Development continuing for over a year
• Refactoring legacy code

Large teams or collaboration-heavy projects:

• 3+ developers working in parallel
• Shared types between frontend and backend
• Frequent onboarding of new team members

Need for reliability and stability:

• Financial, medical, or sensitive data
• B2B enterprise solutions
• Apps with millions of users

When JavaScript Is Enough

JavaScript may suffice in the following cases:

Prototyping and rapid experiments:

• MVP development
• Hackathons or short-term work
• Idea validation

Small or solo projects:

• Individually developed and maintained projects
• Simple landing pages or blogs
• Educational/toy projects

Strong JSDoc usage already in place:

• Well-documented codebase
• Team comfortable with JSDoc
• Migration to TypeScript would be costly

Hybrid Strategies

You don’t have to go all-in. Consider:

Gradual Adoption:

• Write new modules in TypeScript
• Add types to core logic first
• Use allowJs for mixed codebases

Selective Use:

• Use TypeScript for APIs and data models
• Keep utility functions in JavaScript
• Add types only where frameworks require them

TypeScript Is Just a Tool

At its core, this debate isn’t about right vs. wrong. Like DHH, some prefer JavaScript’s simplicity and freedom; others rely on TypeScript’s safety in large systems.

What’s important is to evaluate your project context, your team’s skills, and your business needs. TypeScript is not a silver bullet, and JavaScript is far from obsolete.

With ECMAScript’s type annotation proposal moving forward, the boundary between JS and TS may blur. Somewhere in between lies the best fit for your project.

Ultimately, our goal is to build better software. :)