The Shift Back: Why Some Teams Are Re-evaluating TypeScript

For nearly a decade, TypeScript has been hailed as the unquestioned default standard for modern web development. But recently, notable projects like Svelte, Turbo, and DHH's Rails ecosystem sparked widespread debate by stripping TypeScript builds in favor of vanilla JavaScript with JSDoc typing.

Why the Backlash?

The friction that teams experience with TypeScript rarely stems from static analysis itself. Instead, it comes from the tooling ecosystem surrounding it:

• Build Step Overhead: Compiling, bundling, and sourcemap synchronization slow down developer iteration loops.
• Complex Type Gymnastics: Teams often spend hours wrestling with convoluted generics and conditional type signatures that offer minimal runtime value.
• Dependency Type Discrepancies: Outdated @types packages that mismatch library runtime versions create frustrating roadblocks.

Finding the Pragmatic Balance

JavaScript with rich JSDoc typing offers autocomplete and type checking in modern IDEs without requiring a transpile step.

For mission-critical distributed backends, algorithmic systems, and large multi-team codebases, TypeScript's strict compiler guarantees remain indispensable. But understanding the trade-offs between compile-time friction and developer velocity helps us choose the right tool for each project.

Read on Medium