When DHH announced that Turbo 8 would remove TypeScript from its source, the decision quickly became a referendum on TypeScript. A maintainer’s local choice turned into a rule people wanted to apply to every JavaScript project.
Tool decisions make sense inside the system that has to maintain them.
I use TypeScript in most production applications. It helps refactors cross module boundaries, makes editor navigation useful, and catches mismatched assumptions before runtime. Types also document shared data for engineers reading unfamiliar code.
The value grows with the number of contributors, domain states, public interfaces, and changes moving through the codebase. A large product may recover the cost of type annotations and build tooling through safer daily work.
The team still has to maintain compiler settings, generated types, declaration files, dependency compatibility, and abstractions that may become harder to understand than the runtime behavior. Those costs belong in the decision.
Applications and libraries also serve different environments. An application controls much of its runtime and build pipeline. A library serves many editors, bundlers, module systems, TypeScript versions, and JavaScript users. Its maintainers need to evaluate both the contributor workflow and the public interface shipped to users.
JavaScript source can use JSDoc annotations and publish declaration files. TypeScript source can compile to a small JavaScript package with useful types. Either approach needs an owner for the contributor experience, declaration quality, release process, and compatibility surface.
For Turbo, useful evidence would include maintenance effort, contributor mistakes, declaration quality, release complexity, and user-facing regressions after the change. The repository can show whether JavaScript source improves contributor work and where maintainers need new guardrails.
TypeScript is a strong default for many teams when the reason for that default remains visible. Write down the risks it controls:
- refactors across many modules
- shared contracts between teams
- complex domain states
- public APIs
- generated client and server types
- frequent changes from a large contributor group
Also record the costs that should trigger a review:
- slow builds
- difficult type-level abstractions
- declaration failures
- contributor friction
These signals turn a preference into an engineering decision. Ask which failures the tool prevents, which maintenance work it adds, who carries that work, what interface users receive, and how the project can reverse the choice.
A small library and a large application will often answer those questions differently. Use evidence from the project, the boundary it serves, and the maintenance responsibility the team is prepared to own.